Re: OMAP baseline test results for v3.7-rc1
Hi Kevin, Paul, On Tue, Nov 6, 2012 at 1:01 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: [...] 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. FYI... I just ran across what appears to be the same bug on 3430/n900 during suspend/resume testing. With CPUidle enabled, this happens every time. Reverting the I2C QoS patch makes it work again. That makes sense with CPU_IDLE enabled and suspend. The cause of the problem is that the cpuidle influences the MPU and CORE states, depending on the constraints set and the latency figures for the power domains (in arch/arm/mach-omap2/cpuidle34xx.c). Since the latency numbers have not been updated to measured (i.e. realistic) values in too-low power state is used, hence the timeout problem. Note: that does not explain why the I2C timeout issue is present without CPU_IDLE enabled, since in that case PM QoS should not have any effect on the power domains states. So yes the PM QoS I2C patch shall be reverted as long as the PM QoS support for OMAP is not merged in. For the records here are the patches that have been submitted to support the OMAP PM QoS: - func power states [1], - OMAP PM QoS support [2], which includes the latency figures update and which depends on [1], - the conversion of I2C to PM QoS [3], - the removal of the old no-op OMAP PM API [4], which depends on [3], The chicken-and-egg problem is clearly visible since [3] depends on [2]. What to do now with those patches? As said above [3] and [4] must be held until [1] and [2] are merged in. [1] http://marc.info/?l=linux-arm-kernelm=134744383120921w=2 [2] http://marc.info/?l=linux-omapm=134795835604288w=2 [3] http://marc.info/?l=linux-omapm=134815730108344w=2 [4] http://marc.info/?l=linux-omapm=134795836904299w=2 Kevin Thanks for testing and reporting the issue. Jean # rtcwake -m mem -s 1 Date:Fri Dec 31 17:00:34 MST 1999 hwclock: Sat Jan 1 00:00:34 2000 0.00 seconds [ 38.819732] omap_i2c omap_i2c.1: timeout waiting for bus ready wakeup from mem at Sat Jan 1 00:00:36 2000 [ 38.841949] PM: Syncing filesystems ... done. [ 38.859466] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 38.885284] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 38.916412] Suspending console(s) (use no_console_suspend to debug) [ 39.944274] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 39.944305] twl: i2c_read failed to transfer all messages [ 39.944305] twl_rtc: Could not read TWLregister D - error -110 [ 39.944335] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110 [ 40.975524] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 40.97] twl: i2c_read failed to transfer all messages [ 40.97] VMMC2_IO_18: failed to disable [ 40.978698] PM: suspend of devices complete after 2049.163 msecs [ 40.984222] PM: late suspend of devices complete after 5.493 msecs [ 40.992126] PM: noirq suspend of devices complete after 7.873 msecs [ 40.992187] Disabling non-boot CPUs ... [ 40.992675] Successfully put all powerdomains to target state [ 40.997009] PM: noirq resume of devices complete after 4.058 msecs [ 41.002014] PM: early resume of devices complete after 3.601 msecs [ 41.179016] PM: resume of devices complete after 176.818 msecs [ 41.277740] Restarting tasks ... done. real0m 3.50s user0m 0.00s sys 0m 0.10s Date:Fri Dec 31 17:00:40 MST 1999 hwclock: Sat Jan 1 00:00:40 2000 0.00 seconds -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Tue, Nov 6, 2012 at 5:31 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: [...] 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. FYI... I just ran across what appears to be the same bug on 3430/n900 during suspend/resume testing. With CPUidle enabled, this happens every time. Reverting the I2C QoS patch makes it work again. I think we should defer the release of the constraints Does this help http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79841.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Tue, 6 Nov 2012, Jean Pihet wrote: On Tue, Nov 6, 2012 at 1:01 AM, Kevin Hilman khil...@deeprootsystems.com wrote: FYI... I just ran across what appears to be the same bug on 3430/n900 during suspend/resume testing. With CPUidle enabled, this happens every time. Reverting the I2C QoS patch makes it work again. That makes sense with CPU_IDLE enabled and suspend. ... For the records here are the patches that have been submitted to support the OMAP PM QoS: - func power states [1], - OMAP PM QoS support [2], which includes the latency figures update and which depends on [1], - the conversion of I2C to PM QoS [3], - the removal of the old no-op OMAP PM API [4], which depends on [3], The chicken-and-egg problem is clearly visible since [3] depends on [2]. Well it's definitely time for a revert, then. #3 should not have been sent until #2 was merged. Will send this in a new thread, please ack it. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Paul, On Mon, Nov 5, 2012 at 4:15 AM, Paul Walmsley p...@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 (20 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Jean Pihet jean.pi...@newoldbits.com writes: [...] 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. FYI... I just ran across what appears to be the same bug on 3430/n900 during suspend/resume testing. With CPUidle enabled, this happens every time. Reverting the I2C QoS patch makes it work again. Kevin # rtcwake -m mem -s 1 Date:Fri Dec 31 17:00:34 MST 1999 hwclock: Sat Jan 1 00:00:34 2000 0.00 seconds [ 38.819732] omap_i2c omap_i2c.1: timeout waiting for bus ready wakeup from mem at Sat Jan 1 00:00:36 2000 [ 38.841949] PM: Syncing filesystems ... done. [ 38.859466] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 38.885284] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 38.916412] Suspending console(s) (use no_console_suspend to debug) [ 39.944274] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 39.944305] twl: i2c_read failed to transfer all messages [ 39.944305] twl_rtc: Could not read TWLregister D - error -110 [ 39.944335] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110 [ 40.975524] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 40.97] twl: i2c_read failed to transfer all messages [ 40.97] VMMC2_IO_18: failed to disable [ 40.978698] PM: suspend of devices complete after 2049.163 msecs [ 40.984222] PM: late suspend of devices complete after 5.493 msecs [ 40.992126] PM: noirq suspend of devices complete after 7.873 msecs [ 40.992187] Disabling non-boot CPUs ... [ 40.992675] Successfully put all powerdomains to target state [ 40.997009] PM: noirq resume of devices complete after 4.058 msecs [ 41.002014] PM: early resume of devices complete after 3.601 msecs [ 41.179016] PM: resume of devices complete after 176.818 msecs [ 41.277740] Restarting tasks ... done. real0m 3.50s user0m 0.00s sys 0m 0.10s Date:Fri Dec 31 17:00:40 MST 1999 hwclock: Sat Jan 1 00:00:40 2000 0.00 seconds -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Paul, On Thu, Nov 1, 2012 at 8:51 AM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Paul, On Wed, Oct 31, 2012 at 10:44 PM, Paul Walmsley p...@pwsan.com wrote: Hi On Wed, 31 Oct 2012, Jean Pihet wrote: Paul, Could you please check with the 2 calls to PM QoS from the I2C code commented out? This will rule out the PM QoS impact. Will be happy to do a test run for you, after the boot log from your local test run is posted: http://marc.info/?l=linux-arm-kernelm=135167153510814w=2 Here are some more details after investigation. 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. - 3.7.0-rc1 kernel, omap2plus_defconfig, - same kernel parameters, - Angstrom rootfs from http://www.pwsan.com/tmp/20121023-beagleboard-angstrom-userspace.tar.bz2 The differences are: - OMAP revision (ES2.1 vs ES3.0), - Beagleboard revision (B5 vs Cx), - RAM amount (128 vs 256MB), - compiler: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) vs 4.5.2 (Sourcery G++ Lite 2011.03-41) 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). The issue is triggered by running 'hwclock --systohc' while the system is heavily loaded (running depmod etc.). The system recovers nicely after the issue, the RTC can be used correctly later on. Here is the log: U-Boot 2011.06-dirty (Sep 04 2012 - 17:06:58) OMAP3530-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 128 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 In:serial Out: serial Err: serial Beagle Rev Ax/Bx timed out in wait_for_pin: I2C_STAT=0 I2C read: I/O error Unrecognized expansion board: 0 Die ID #0f6204013ef109008009 Hit any key to stop autoboot: 0 reading uimage 4148008 bytes read ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux-3.7.0-rc1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4147944 Bytes = 4 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.7.0-rc1 (def@rachael) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #2 SMP Sat Nov 3 21:56:11 CET 2012 [0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3 Beagle Board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [0.00] PERCPU: Embedded 9 pages/cpu @c0e4 s12928 r8192 d15744 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [0.00] Kernel command line: console=ttyO2,230400n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 127MB = 127MB total [0.00] Memory: 115316k/115316k available, 15756k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc880 - 0xff00 ( 872 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc07037dc (7150 kB) [0.00] .init : 0xc0704000 - 0xc0754280 ( 321 kB) [0.00] .data : 0xc0756000 - 0xc07e15a0 ( 558 kB) [0.00].bss : 0xc07e15c4 - 0xc0d3bfac (5483 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] OMAP clocksource: 32k_counter at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [
Re: OMAP baseline test results for v3.7-rc1
Hi Paul, On Wed, Oct 31, 2012 at 10:44 PM, Paul Walmsley p...@pwsan.com wrote: Hi On Wed, 31 Oct 2012, Jean Pihet wrote: Paul, Could you please check with the 2 calls to PM QoS from the I2C code commented out? This will rule out the PM QoS impact. Will be happy to do a test run for you, after the boot log from your local test run is posted: http://marc.info/?l=linux-arm-kernelm=135167153510814w=2 As said earlier [1] the test has been done already. I did check the boot messages and tried to read/write the RTC. All test were successfull and the only difference in the logs was the absence of the I2C timeout messages. I can redo the tests and provide a log but that will not happen before Saturday. [1] http://marc.info/?l=linux-omapm=135161909714517w=2 Regards, Jean - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Paul, On Tue, Oct 30, 2012 at 7:23 AM, Paul Walmsley p...@pwsan.com wrote: Hi Jean, On Tue, 30 Oct 2012, Jean Pihet wrote: On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 23 Oct 2012, Jean Pihet wrote: Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). Had any luck reproducing this one that Aaro I are seeing? Unfortunately not. I could not reproduce the issue on my side, using an ES2.1 Beagleboard with the latest l-o kernel and your bootloader and rootfs images. Is there some specific to enable in order to reproduce the issue? Could you please post a bootlog from your terminal program, similar to http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/boot/3530es3beagle/3530es3beagle_log.txt ? Yes sure. Let me try to reproduce the problem again. As said previously I cannot have the timeouts issue. More to come. Jean - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Tue, Oct 30, 2012 at 9:17 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 30 Oct 2012, Felipe Balbi wrote: On Tue, Oct 30, 2012 at 12:50:52PM +, Paul Walmsley wrote: certainly PM-idle related, given that the problem goes away by reverting Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints. The problem is consistent and easy to reproduce here. I don't doubt that :-) What I think, however, is that PM QoS just made I dont doubt either but cannot have it reproduced. the problem a bit easier to trigger for whatever reason. Maybe because pm qos defers constraint updates, or something similar ? PM QoS just influences the cpuidle decision on the next power state of the CPU and CORE power domains. Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. Withtout CPU_IDLE set the PM QoS has no influence on the power domains states. - Paul Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Paul, - Added Rafael for the PM QoS discussion - On Tue, Oct 30, 2012 at 10:04 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 30 Oct 2012, Paul Walmsley wrote: Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. So in fact to follow up on this, looks like one of two changes are needed: 1. Revert 3db11fe or 2. If CONFIG_CPU_IDLE=n, the driver needs to call disable_hlt() in place of the pm_qos constraint add, and call enable_hlt() in place of the pm_qos constraint remove. I do not think this is correct. Using disable_hlt is a too radical solution and will prevent the idle completely, this is not what we want. Rafael, what do you think? Furthermore without the patch 3db11fe enable_hlt and disable_hlt are not used in the driver so this change is not the real fix for the issue. To me the cause is somewhere else. I was hoping Felipe's ordering fix would do it... Jean, could you please pick a solution and send a patch for the 3.7-rc timeframe, to fix the bug in 3db11fe? ? Let me try to reproduce the issue and hopefully investigate a bit more. Feel free to revert the patch if you feel like it is the thing to do. - Paul Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Wednesday, October 31, 2012 04:34:21 AM Jean Pihet wrote: Paul, - Added Rafael for the PM QoS discussion - On Tue, Oct 30, 2012 at 10:04 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 30 Oct 2012, Paul Walmsley wrote: Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. So in fact to follow up on this, looks like one of two changes are needed: 1. Revert 3db11fe or 2. If CONFIG_CPU_IDLE=n, the driver needs to call disable_hlt() in place of the pm_qos constraint add, and call enable_hlt() in place of the pm_qos constraint remove. I do not think this is correct. Using disable_hlt is a too radical solution and will prevent the idle completely, this is not what we want. Rafael, what do you think? Well, I agree. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: [...] Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. Withtout CPU_IDLE set the PM QoS has no influence on the power domains states. Exactly, which means there is *no* constraint set when CPUidle is disabled, and it's exactly this that is different from the behavior before your patch. Before your patch, the constraint would be set whether or not CPUidle was enabled, correct? The solution to this will probably be to make OMAPs non-CPUidle idle path check the constraints. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Kevin, On Wed, Oct 31, 2012 at 6:49 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: [...] Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. Withtout CPU_IDLE set the PM QoS has no influence on the power domains states. Exactly, which means there is *no* constraint set when CPUidle is disabled, Correct. With CPU_IDLE disabled PM QoS manages the constraints list but cpuidle does not request the aggregated value nor does it restrict the CPU and CORE power domains states. and it's exactly this that is different from the behavior before your patch. No. Before your patch, the constraint would be set whether or not CPUidle was enabled, correct? No. In the linux-omap source tree the OMAP PM API for the latency constraints simply is a no-op. The only difference with the code after the patch is that PM QoS manages the constraints list, which should be neglictable in terms of CPU execution time. Paul, Could you please check with the 2 calls to PM QoS from the I2C code commented out? This will rule out the PM QoS impact. The solution to this will probably be to make OMAPs non-CPUidle idle path check the constraints. This is the idea behind the per-device PM QoS support, which allows to set a constraint on any device and so on any power domain (note that cpuidle influences CPU and CORE only). However in the current context -the I2C timeouts issue- there is no apparent link between the issue and the patch 3db11fef [1]. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=3db11feffc1ad2ab9dea27789e6b5b3032827adc Kevin Thanks, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi On Wed, 31 Oct 2012, Jean Pihet wrote: Paul, Could you please check with the 2 calls to PM QoS from the I2C code commented out? This will rule out the PM QoS impact. Will be happy to do a test run for you, after the boot log from your local test run is posted: http://marc.info/?l=linux-arm-kernelm=135167153510814w=2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Paul, On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley p...@pwsan.com wrote: Hello Jean, On Tue, 23 Oct 2012, Jean Pihet wrote: Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). Had any luck reproducing this one that Aaro I are seeing? Unfortunately not. I could not reproduce the issue on my side, using an ES2.1 Beagleboard with the latest l-o kernel and your bootloader and rootfs images. Is there some specific to enable in order to reproduce the issue? Regards, Jean - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Jean, On Tue, 30 Oct 2012, Jean Pihet wrote: On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 23 Oct 2012, Jean Pihet wrote: Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). Had any luck reproducing this one that Aaro I are seeing? Unfortunately not. I could not reproduce the issue on my side, using an ES2.1 Beagleboard with the latest l-o kernel and your bootloader and rootfs images. Is there some specific to enable in order to reproduce the issue? Could you please post a bootlog from your terminal program, similar to http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/boot/3530es3beagle/3530es3beagle_log.txt ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi, On Tue, Oct 30, 2012 at 12:17:11PM +, Paul Walmsley wrote: On Mon, 29 Oct 2012, Felipe Balbi wrote: that's too bad :-( Can you compile with: CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_ALGO=y CONFIG_I2C_DEBUG_BUS=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=9 so that I can see all transfers ? Log is below. that's working. It only helps to let me know we have a race somewhere, and if it is what I'm thinking, the wmb() patch should help, but you said it doesn't, right ? without seeing debugging information on the failing case, it'll be very difficult to sort this one out provided noone else seems to be able to reproduce it. -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
On Tue, 30 Oct 2012, Felipe Balbi wrote: the wmb() patch should help, but you said it doesn't, right ? Correct. Not sure why you think that would help; the problem is almost certainly PM-idle related, given that the problem goes away by reverting Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints. The problem is consistent and easy to reproduce here. without seeing debugging information on the failing case, it'll be very difficult to sort this one out provided noone else seems to be able to reproduce it. Aaro sees it also, so it's definitely not a local artifact. It's not very surprising that the problem doesn't appear with the extra logging enabled, since the extra logging presumably keeps the system out of idle. Anyway, you are welcome to the userspace, bootloader, and X-loader here if you would like to try to reproduce it. They've been sent to Jean and Kevin and Shubhrajyoti already. Simply request it and I will send links. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi, On Tue, Oct 30, 2012 at 12:50:52PM +, Paul Walmsley wrote: On Tue, 30 Oct 2012, Felipe Balbi wrote: the wmb() patch should help, but you said it doesn't, right ? Correct. Not sure why you think that would help; the problem is almost because of how the driver is behaving... The only way for omap_i2c_wait_for_bb() to timeout is if the bus is really still busy; meaning that either transfer hasn't fully completed (some data still in FIFO), or we didn't send STOP or Repeated START condition on the bus. certainly PM-idle related, given that the problem goes away by reverting Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints. The problem is consistent and easy to reproduce here. I don't doubt that :-) What I think, however, is that PM QoS just made the problem a bit easier to trigger for whatever reason. Maybe because pm qos defers constraint updates, or something similar ? without seeing debugging information on the failing case, it'll be very difficult to sort this one out provided noone else seems to be able to reproduce it. Aaro sees it also, so it's definitely not a local artifact. Again I don't doubt it. It's not very surprising that the problem doesn't appear with the extra logging enabled, since the extra logging presumably keeps the system out of idle. Anyway, you are welcome to the userspace, bootloader, and X-loader here if you would like to try to reproduce it. They've been sent to Jean and Kevin and Shubhrajyoti already. Simply request it and I will send links. I can have a look, sure, but I don't have the same platform as you have. I have a beagle XM revB (according to the stickers on the board) which I could use to try to reproduce, if I manage to, then hooray :-) In that case, please give me also a link to your uImage so I can make sure to use the exact same setup. cheers -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
On Tue, 30 Oct 2012, Felipe Balbi wrote: On Tue, Oct 30, 2012 at 12:50:52PM +, Paul Walmsley wrote: certainly PM-idle related, given that the problem goes away by reverting Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints. The problem is consistent and easy to reproduce here. I don't doubt that :-) What I think, however, is that PM QoS just made the problem a bit easier to trigger for whatever reason. Maybe because pm qos defers constraint updates, or something similar ? Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Tue, 30 Oct 2012, Paul Walmsley wrote: Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. So in fact to follow up on this, looks like one of two changes are needed: 1. Revert 3db11fe or 2. If CONFIG_CPU_IDLE=n, the driver needs to call disable_hlt() in place of the pm_qos constraint add, and call enable_hlt() in place of the pm_qos constraint remove. Jean, could you please pick a solution and send a patch for the 3.7-rc timeframe, to fix the bug in 3db11fe? ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi, On Fri, Oct 26, 2012 at 10:03:11PM +, Paul Walmsley wrote: Hi Felipe, On Fri, 26 Oct 2012, Felipe Balbi wrote: On Thu, Oct 25, 2012 at 01:12:12PM +0300, Felipe Balbi wrote: On Tue, Oct 23, 2012 at 09:23:03PM +0200, Jean Pihet wrote: On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 22 Oct 2012, Jean Pihet wrote: On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Do you have CPU_IDLE enabled? FYI the issue is not present with CPU_IDLE enabled. Hmm, how can you tell? I thought you weren't able to reproduce it with CPU_IDLE disabled either? I could not reproduce the issue, with and without CPU_IDLE enabled. What puzzles me is that the PM QoS code only has influence on the states chosen by cpuidle, so the change should not have any impact with CPU_IDLE enabled. I reallt need to reproduce the issue. Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). I just sent a patch to fix a bug I found on OMAP4 panda but while reading this thread again, I think it could be that it's the same bug which is just easier to reproduce on Paul's setup. Paul, Aaro, can you see if [1] makes the problem go away ? that would be another reason to push [1] during this -rc cycle. [1] http://marc.info/?l=linux-omapm=135115602407925w=2 Thanks for mentioning it, but this patch doesn't fix the I2C timeout problem here. Log fragment below from the 3530ES3 Beagle. that's too bad :-( Can you compile with: CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_ALGO=y CONFIG_I2C_DEBUG_BUS=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=9 so that I can see all transfers ? -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
Hello Jean, On Tue, 23 Oct 2012, Jean Pihet wrote: Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). Had any luck reproducing this one that Aaro I are seeing? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi, On Thu, Oct 25, 2012 at 01:12:12PM +0300, Felipe Balbi wrote: Hi, On Tue, Oct 23, 2012 at 09:23:03PM +0200, Jean Pihet wrote: On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 22 Oct 2012, Jean Pihet wrote: On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Do you have CPU_IDLE enabled? FYI the issue is not present with CPU_IDLE enabled. Hmm, how can you tell? I thought you weren't able to reproduce it with CPU_IDLE disabled either? I could not reproduce the issue, with and without CPU_IDLE enabled. What puzzles me is that the PM QoS code only has influence on the states chosen by cpuidle, so the change should not have any impact with CPU_IDLE enabled. I reallt need to reproduce the issue. Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). I just sent a patch to fix a bug I found on OMAP4 panda but while reading this thread again, I think it could be that it's the same bug which is just easier to reproduce on Paul's setup. Paul, Aaro, can you see if [1] makes the problem go away ? that would be another reason to push [1] during this -rc cycle. [1] http://marc.info/?l=linux-omapm=135115602407925w=2 ping -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
Hi Felipe, On Fri, 26 Oct 2012, Felipe Balbi wrote: On Thu, Oct 25, 2012 at 01:12:12PM +0300, Felipe Balbi wrote: On Tue, Oct 23, 2012 at 09:23:03PM +0200, Jean Pihet wrote: On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 22 Oct 2012, Jean Pihet wrote: On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Do you have CPU_IDLE enabled? FYI the issue is not present with CPU_IDLE enabled. Hmm, how can you tell? I thought you weren't able to reproduce it with CPU_IDLE disabled either? I could not reproduce the issue, with and without CPU_IDLE enabled. What puzzles me is that the PM QoS code only has influence on the states chosen by cpuidle, so the change should not have any impact with CPU_IDLE enabled. I reallt need to reproduce the issue. Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). I just sent a patch to fix a bug I found on OMAP4 panda but while reading this thread again, I think it could be that it's the same bug which is just easier to reproduce on Paul's setup. Paul, Aaro, can you see if [1] makes the problem go away ? that would be another reason to push [1] during this -rc cycle. [1] http://marc.info/?l=linux-omapm=135115602407925w=2 Thanks for mentioning it, but this patch doesn't fix the I2C timeout problem here. Log fragment below from the 3530ES3 Beagle. - Paul Starting portmap daemon: portmap. Tue Jul 22 00:18:00 UTC 2008 [ 23.476684] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 24.492309] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 24.495574] twl: i2c_read failed to transfer all messages [ 24.498535] twl_rtc: Could not read TWLregister D - error -110 [ 24.501800] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110 INIT: Entering runlevel: 5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi, On Tue, Oct 23, 2012 at 09:23:03PM +0200, Jean Pihet wrote: On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 22 Oct 2012, Jean Pihet wrote: On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Do you have CPU_IDLE enabled? FYI the issue is not present with CPU_IDLE enabled. Hmm, how can you tell? I thought you weren't able to reproduce it with CPU_IDLE disabled either? I could not reproduce the issue, with and without CPU_IDLE enabled. What puzzles me is that the PM QoS code only has influence on the states chosen by cpuidle, so the change should not have any impact with CPU_IDLE enabled. I reallt need to reproduce the issue. Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). I just sent a patch to fix a bug I found on OMAP4 panda but while reading this thread again, I think it could be that it's the same bug which is just easier to reproduce on Paul's setup. Paul, Aaro, can you see if [1] makes the problem go away ? that would be another reason to push [1] during this -rc cycle. [1] http://marc.info/?l=linux-omapm=135115602407925w=2 -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
Jean Pihet jean.pi...@newoldbits.com writes: Hi, On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley p...@pwsan.com wrote: Hi Jean On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation Boot tests: * 3530ES3 Beagle: I2C timeouts during userspace init - May be related to the threaded IRQ conversion of the I2C driver - Unknown cause This one turned out to be caused by: commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc Author: Jean Pihet jean.pi...@newoldbits.com Date: Thu Sep 20 18:08:03 2012 +0200 ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints Reverting this commit causes the problem to go away, but since the OMAP PM constraint code was removed as well, it's unlikely that a simple revert is the right thing to do. Jean could you please investigate and fix this? I tried the latest l-o with omap2plus defconfig on my Beagleboard B5 (ES2.1) and could not reproduce the problem. I do not have the I2C error messages at boot, nor at user space start up. I tried to read/write the TWL RTC, successfully. Another difference is the bootloader images. I have the following: - Texas Instruments X-Loader 1.4.2 (Feb 3 2009 - 15:34:17) - U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31) Could you send your bootloader images? I noticed you have I2C error messages in U-Boot, could that be the cause of the I2C lock-up? FWIW, I have a relatively recent mainline u-boot+SPL: U-Boot SPL 2012.04.01 (Jul 03 2012 - 07:07:04) U-Boot 2012.04.01 (Jul 03 2012 - 07:07:04) And I see I2C error messages from u-boot too: timed out in wait_for_pin: I2C_STAT=0 I2C read: I/O error I think these are normal/expected since u-boot may be looking for expansion cards. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi On Mon, 22 Oct 2012, Jean Pihet wrote: I tried the latest l-o with omap2plus defconfig on my Beagleboard B5 (ES2.1) and could not reproduce the problem. I do not have the I2C error messages at boot, nor at user space start up. I tried to read/write the TWL RTC, successfully. Another difference is the bootloader images. I have the following: - Texas Instruments X-Loader 1.4.2 (Feb 3 2009 - 15:34:17) - U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31) Could you send your bootloader images? Just sent you a link via private E-mail. On the PM QoS side the commit 3db11fef moves the I2C code from the OMAP PM no-op layer to the PM QoS for CPU and DMA latency, which influences the cpuidle states. However CPU_IDLE is not set in omap2plus_defconfig so there should not be any effect. Do you have CPU_IDLE enabled? No, it's omap2plus_defconfig. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Mon, 22 Oct 2012, Jean Pihet wrote: On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Do you have CPU_IDLE enabled? FYI the issue is not present with CPU_IDLE enabled. Hmm, how can you tell? I thought you weren't able to reproduce it with CPU_IDLE disabled either? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 22 Oct 2012, Jean Pihet wrote: On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Do you have CPU_IDLE enabled? FYI the issue is not present with CPU_IDLE enabled. Hmm, how can you tell? I thought you weren't able to reproduce it with CPU_IDLE disabled either? I could not reproduce the issue, with and without CPU_IDLE enabled. What puzzles me is that the PM QoS code only has influence on the states chosen by cpuidle, so the change should not have any impact with CPU_IDLE enabled. I reallt need to reproduce the issue. Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). Regards, Jean - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi, On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley p...@pwsan.com wrote: Hi Jean On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation Boot tests: * 3530ES3 Beagle: I2C timeouts during userspace init - May be related to the threaded IRQ conversion of the I2C driver - Unknown cause This one turned out to be caused by: commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc Author: Jean Pihet jean.pi...@newoldbits.com Date: Thu Sep 20 18:08:03 2012 +0200 ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints Reverting this commit causes the problem to go away, but since the OMAP PM constraint code was removed as well, it's unlikely that a simple revert is the right thing to do. Jean could you please investigate and fix this? I tried the latest l-o with omap2plus defconfig on my Beagleboard B5 (ES2.1) and could not reproduce the problem. I do not have the I2C error messages at boot, nor at user space start up. I tried to read/write the TWL RTC, successfully. Another difference is the bootloader images. I have the following: - Texas Instruments X-Loader 1.4.2 (Feb 3 2009 - 15:34:17) - U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31) Could you send your bootloader images? I noticed you have I2C error messages in U-Boot, could that be the cause of the I2C lock-up? On the PM QoS side the commit 3db11fef moves the I2C code from the OMAP PM no-op layer to the PM QoS for CPU and DMA latency, which influences the cpuidle states. However CPU_IDLE is not set in omap2plus_defconfig so there should not be any effect. Do you have CPU_IDLE enabled? - Paul Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sat, 2012-10-20 at 17:20 +, Paul Walmsley wrote: Hello Venkatraman, On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation ... PM tests: * 3530es3beagle: hangs during off-mode dynamic idle test - Unknown cause; not investigated Looks like this commit is causing some of our power management tests to fail on v3.7-rc1: commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c Author: Venkatraman S svenk...@ti.com Date: Wed Aug 8 14:26:52 2012 +0530 mmc: omap_hsmmc: remove access to SYSCONFIG register ... The failure can be seen in the following test log: http://www.pwsan.com/omap/transcripts/20121020-3530es3beagle-off-mode-fail-pre-revert.txt and with commit 6c31b215 reverted, the test succeeds: http://www.pwsan.com/omap/transcripts/20121020-3530es3beagle-off-mode-fail-post-revert.txt Could you please take a look and fix the problem? Root cause for this issue is that the MMC IP is reset during off-mode, but the driver doesn't expect this in its current form. There are a couple of alternative ways to fix this. Either add a reset timeout to the MMC driver code (which was removed by the bisected patch), or alternatively add a global reset check to the hwmod code. I'll send a patch for the global reset purpose in a bit for commenting. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Aaro Koskinen aaro.koski...@iki.fi writes: Hi, On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote: On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote: FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c omap_i2c.1: timeout waiting for bus ready). After several reboots they disappered (kernel binary was the same), and I have been unable to reproduce them since. any change you have those logs saved somewhere ? Want to see if it's the same problem triggered by RTC. I did not save the logs, but now I tried again, I managed to reproduce it after couple boots. The log is below, and after that the there's also one from OK boot for comparison. In the error case, the boot never reaches userspace, just silently hangs (or maybe I just didn't wait enough long). Can you try to revert the threaded IRQ conversion to see if things get to working again? commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi, On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley p...@pwsan.com wrote: Hi Jean On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation Boot tests: * 3530ES3 Beagle: I2C timeouts during userspace init - May be related to the threaded IRQ conversion of the I2C driver - Unknown cause This one turned out to be caused by: commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc Author: Jean Pihet jean.pi...@newoldbits.com Date: Thu Sep 20 18:08:03 2012 +0200 ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints Reverting this commit causes the problem to go away, but since the OMAP PM constraint code was removed as well, it's unlikely that a simple revert is the right thing to do. Jean could you please investigate and fix this? I tried the latest l-o with omap2plus defconfig on my Beagleboard B5 (ES2.1) and could not reproduce the problem. I do not have the I2C error messages at boot, nor at user space start up. I tried to read/write the TWL RTC, successfully. Another difference is the bootloader images. I have the following: - Texas Instruments X-Loader 1.4.2 (Feb 3 2009 - 15:34:17) - U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31) Could you send your bootloader images? I noticed you have I2C error messages in U-Boot, could that be the cause of the I2C lock-up? On the PM QoS side the commit 3db11fef moves the I2C code from the OMAP PM no-op layer to the PM QoS for CPU and DMA latency, which influences the cpuidle states. However CPU_IDLE is not set in omap2plus_defconfig so there should not be any effect. Do you have CPU_IDLE enabled? FYI the issue is not present with CPU_IDLE enabled. Regards, Jean - Paul Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Paul Walmsley p...@pwsan.com writes: Hi Kevin On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation ... PM tests: * 3730 Beagle XM: OPPs do not initialize - Several find_device_opp: Invalid parameters messages appear on boot; related warnings follow - Cause unknown This one seems to be caused by this commit: commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 Author: Kevin Hilman khil...@ti.com Date: Thu Sep 6 14:03:08 2012 -0700 ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS Care to take a look at it and fix it? Yup, will fix. Looks like this exposed some initcall ordering issues in the Beagle board file when adding OPPs. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Kevin Hilman khil...@deeprootsystems.com writes: Aaro Koskinen aaro.koski...@iki.fi writes: Hi, On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote: On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote: FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c omap_i2c.1: timeout waiting for bus ready). After several reboots they disappered (kernel binary was the same), and I have been unable to reproduce them since. any change you have those logs saved somewhere ? Want to see if it's the same problem triggered by RTC. I did not save the logs, but now I tried again, I managed to reproduce it after couple boots. The log is below, and after that the there's also one from OK boot for comparison. In the error case, the boot never reaches userspace, just silently hangs (or maybe I just didn't wait enough long). Can you try to revert the threaded IRQ conversion to see if things get to working again? commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde Nevermind, Paul seems to have already isolated the problem on this one. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Kevin Hilman khil...@deeprootsystems.com writes: Paul Walmsley p...@pwsan.com writes: Hi Kevin On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation ... PM tests: * 3730 Beagle XM: OPPs do not initialize - Several find_device_opp: Invalid parameters messages appear on boot; related warnings follow - Cause unknown This one seems to be caused by this commit: commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 Author: Kevin Hilman khil...@ti.com Date: Thu Sep 6 14:03:08 2012 -0700 ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS Care to take a look at it and fix it? Yup, will fix. Looks like this exposed some initcall ordering issues in the Beagle board file when adding OPPs. Here's the fix: http://marc.info/?l=linux-omapm=135093801330065w=2 I'll be adding this to my PM-related fixes queue for v3.7-rc3. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Matt Porter mpor...@ti.com writes: On Sat, Oct 20, 2012 at 06:58:10PM +, Paul Walmsley wrote: On Sat, 20 Oct 2012, Richard Cochran wrote: On Sat, Oct 20, 2012 at 06:12:35PM +, Paul Walmsley wrote: Just tried omap2plus_defconfig here and the board didn't boot, confirming your result. Will add a section to the testlog README.txt about that. In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. I tried both omap2plus_defconfig and your am33xx_only config, and neither one work with my (recent) u-boot version. Just sent you the MLO and u-boot.img from here via private E-mail. Those were the files that came with the BeagleBone SD card here. TI also has a u-boot tree for the AM33xx; might be worth trying: git://arago-project.org/git/projects/u-boot-am33x.git Use of the vendor tree should be discouraged. The best thing to use is current ToT U-Boot mainline or the v2012.10 stable U-Boot release. X-Loader is deprecated by U-Boot SPL. Just FYI for anyone else having an older BeagleBone. On my Rev A2, using u-boot mainline, neither HEAD or v2012.10 result in a working network interface, so you can't netboot/dhcp. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sat, Oct 20, 2012 at 04:27:19PM +, Paul Walmsley wrote: Here's the console log from the boot test here: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/am335xbone/am335xbone_log.txt And here's the kernel config and uImage+DTB from the boot test here: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/build/am33xx_only/ In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. Paul, You are using an obsolete u-boot and the legacy appended dtb method. It was my understanding that that way is just a temporary hack in case the boot loader does not support dtb. Now that u-boot has the proper support, using the dtb method is the offical boot method, AFAICT. At least, that is what people are saying on the arm list. So I think that if you want to test whether a particular board is booting correctly, it is more useful to try the offical method. People keep saying, the beaglebone works fine with v3.7-rc1, but it isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been fixed, and no one is doing anything about it either. When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sun, 21 Oct 2012, Richard Cochran wrote: You are using an obsolete u-boot and the legacy appended dtb method. It was my understanding that that way is just a temporary hack in case the boot loader does not support dtb. Now that u-boot has the proper support, using the dtb method is the offical boot method, AFAICT. At least, that is what people are saying on the arm list. So I think that if you want to test whether a particular board is booting correctly, it is more useful to try the offical method. I'm not interested in testing the bootloader, only the kernel. And in particular, my focus is currently on the OMAP-specific parts of the boot and the PM code, not any kernel DT code. People keep saying, the beaglebone works fine with v3.7-rc1, but it isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been fixed, and no one is doing anything about it either. There's likely to be quite a bit that doesn't work in the AM335x boards in mainline, due to the fact that it's the first OMAP DT-only board. Many device drivers and subsystems are still not fully adapted to DT across most ARM boards. When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Really? What section of the message provided that to you? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sun, Oct 21, 2012 at 08:23:35AM +, Paul Walmsley wrote: On Sun, 21 Oct 2012, Richard Cochran wrote: When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Really? What section of the message provided that to you? It was the part that said, Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone It sounded to me like you were saying that the current kernel release boots just fine on the beaglebone, with no issues. It surprised me, because in fact I have had one heck of a time getting the beaglebone to boot. It is a bit of a cop-out to say that you are not interested in the boot loader. Way back when the whole dt is so cool, arm should use it too argument appeared, I wrote that, in my experience with Freescale powerpc chips, the whole kernel/dt/u-boot is a kind of Bermuda Triangle of misfortune. Looks like that dt is turning out to be just as successful for arm as it was for powerpc. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.7-rc1
Hi Richard, * Richard Cochran, October 21, 2012 1:05 PM: People keep saying, the beaglebone works fine with v3.7-rc1, but it isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been fixed, and no one is doing anything about it either. A fix to resolve the gpmc issue has been merged recently, so I am expecting beagle bone to boot on -rc2 (I don't have hardware to test, on vacation now), can you please try with -rc2. Note: Sending via exchange, hope this is readable. Regards Afzal-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sun, Oct 21, 2012 at 12:29:26PM +, Mohammed, Afzal wrote: Hi Richard, * Richard Cochran, October 21, 2012 1:05 PM: People keep saying, the beaglebone works fine with v3.7-rc1, but it isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been fixed, and no one is doing anything about it either. A fix to resolve the gpmc issue has been merged recently, so I am expecting beagle bone to boot on -rc2 (I don't have hardware to test, on vacation now), can you please try with -rc2. I am happy to report that v3.7-rc2 boots via the modern DT method, using Paul's am33xx_only config and U-Boot 2012.10-rc1-00148-g4668a08. Thanks, and have a nice vacation, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sat, Oct 20, 2012 at 06:58:10PM +, Paul Walmsley wrote: On Sat, 20 Oct 2012, Richard Cochran wrote: On Sat, Oct 20, 2012 at 06:12:35PM +, Paul Walmsley wrote: Just tried omap2plus_defconfig here and the board didn't boot, confirming your result. Will add a section to the testlog README.txt about that. In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. I tried both omap2plus_defconfig and your am33xx_only config, and neither one work with my (recent) u-boot version. Just sent you the MLO and u-boot.img from here via private E-mail. Those were the files that came with the BeagleBone SD card here. TI also has a u-boot tree for the AM33xx; might be worth trying: git://arago-project.org/git/projects/u-boot-am33x.git Use of the vendor tree should be discouraged. The best thing to use is current ToT U-Boot mainline or the v2012.10 stable U-Boot release. X-Loader is deprecated by U-Boot SPL. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sun, 21 Oct 2012, Richard Cochran wrote: On Sun, Oct 21, 2012 at 08:23:35AM +, Paul Walmsley wrote: On Sun, 21 Oct 2012, Richard Cochran wrote: When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Really? What section of the message provided that to you? It was the part that said, Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone It sounded to me like you were saying that the current kernel release boots just fine on the beaglebone, with no issues. Which it does here, on the configuration described earlier: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/am335xbone/am335xbone_log.txt - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sun, 21 Oct 2012, Matt Porter wrote: On Sat, Oct 20, 2012 at 06:58:10PM +, Paul Walmsley wrote: TI also has a u-boot tree for the AM33xx; might be worth trying: git://arago-project.org/git/projects/u-boot-am33x.git Use of the vendor tree should be discouraged. That's good. Maybe someone can drop a comment to that effect into the top of the arago u-boot README? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Jean On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation Boot tests: * 3530ES3 Beagle: I2C timeouts during userspace init - May be related to the threaded IRQ conversion of the I2C driver - Unknown cause This one turned out to be caused by: commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc Author: Jean Pihet jean.pi...@newoldbits.com Date: Thu Sep 20 18:08:03 2012 +0200 ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints Reverting this commit causes the problem to go away, but since the OMAP PM constraint code was removed as well, it's unlikely that a simple revert is the right thing to do. Jean could you please investigate and fix this? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Kevin On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation ... PM tests: * 3730 Beagle XM: OPPs do not initialize - Several find_device_opp: Invalid parameters messages appear on boot; related warnings follow - Cause unknown This one seems to be caused by this commit: commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 Author: Kevin Hilman khil...@ti.com Date: Thu Sep 6 14:03:08 2012 -0700 ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS Care to take a look at it and fix it? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Thu, Oct 18, 2012 at 05:20:46AM +, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ Changes from previous tests --- Kernel configs have been reorganized and updated. AM335x Beaglebone and OMAP4460 Pandaboard-ES boards have been added to the testbed. Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) BeagleBone Rev. A6 does not boot v3.7-rc1, at least not for me. I recently posted the missing patches needed to make it work (but the patches are not by me). Below I include the console log. Thanks, Richard U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 3 0 U-Boot# tftp 8100 uImage link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 192.168.0.12; our IP address is 192.168.0.77 Filename 'uImage'. Load address: 0x8100 Loading: # # # # # # # # # # # done Bytes transferred = 3822248 (3a52a8 hex) U-Boot#tftp 8200 beaglebone-initrd.gz link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 192.168.0.12; our IP address is 192.168.0.77 Filename 'beaglebone-initrd.gz'. Load address: 0x8200 Loading: # # # # # # # done Bytes transferred = 2059309 (1f6c2d hex) U-Boot#tftp 8000 am335x-bone.dtb link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 192.168.0.12; our IP address is 192.168.0.77 Filename 'am335x-bone.dtb'. Load address: 0x8000 Loading: # done Bytes transferred = 4391 (1127 hex) U-Boot#bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.7.0-rc1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3822184 Bytes = 3.6 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe66000, end 8fe6a126 ... OK Starting kernel ... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Richard On Sat, 20 Oct 2012, Richard Cochran wrote: On Thu, Oct 18, 2012 at 05:20:46AM +, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone ... BeagleBone Rev. A6 does not boot v3.7-rc1, at least not for me. I recently posted the missing patches needed to make it work (but the patches are not by me). Those are the patches at: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html ? Below I include the console log. Thanks for the report. Are you using the stock v3.7-rc1 DTS file in arch/arm/boot/dts/am335x-bone.dts ? Also are you using omap2plus_defconfig? ... Here's the console log from the boot test here: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/am335xbone/am335xbone_log.txt And here's the kernel config and uImage+DTB from the boot test here: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/build/am33xx_only/ In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hello Venkatraman, On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation ... PM tests: * 3530es3beagle: hangs during off-mode dynamic idle test - Unknown cause; not investigated Looks like this commit is causing some of our power management tests to fail on v3.7-rc1: commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c Author: Venkatraman S svenk...@ti.com Date: Wed Aug 8 14:26:52 2012 +0530 mmc: omap_hsmmc: remove access to SYSCONFIG register ... The failure can be seen in the following test log: http://www.pwsan.com/omap/transcripts/20121020-3530es3beagle-off-mode-fail-pre-revert.txt and with commit 6c31b215 reverted, the test succeeds: http://www.pwsan.com/omap/transcripts/20121020-3530es3beagle-off-mode-fail-post-revert.txt Could you please take a look and fix the problem? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Thu, 18 Oct 2012, Santosh Shilimkar wrote: On Thursday 18 October 2012 02:07 PM, Tero Kristo wrote: On Thu, 2012-10-18 at 06:48 +, Paul Walmsley wrote: * 4430es2panda: clockevents problems early in boot - boots with dummy_timer - no one-shot mode so no-HZ is likely to fail I have a fix for this problem, however I am seeing this on omap4460 panda. The root cause seems to be that local timer init for OMAP is using wrong interrupt number. It adds a wrong offset to the interrupt (OMAP_INTC_START) which should be omitted. Will send a patch soon along with a new version of core ret set. This one is already fixed by [1] and Tony has sent pull request[1] to arm-soc maintainers for 3.7-rc1 which includes the fix. Thanks, I've updated http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/README.txt - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sat, Oct 20, 2012 at 04:27:19PM +, Paul Walmsley wrote: BeagleBone Rev. A6 does not boot v3.7-rc1, at least not for me. I recently posted the missing patches needed to make it work (but the patches are not by me). Those are the patches at: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html ? Yes, that is right. Only the first patch is absoutely required for booting. Thanks for the report. Are you using the stock v3.7-rc1 DTS file in arch/arm/boot/dts/am335x-bone.dts ? Yes. Also are you using omap2plus_defconfig? Yes, but I de-selected a few items. I will try it again without changing anything. Here's the console log from the boot test here: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/am335xbone/am335xbone_log.txt And here's the kernel config and uImage+DTB from the boot test here: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/build/am33xx_only/ Okay, so there are a number of differences between your am33xx_only and the omap2plus_defconfig. I will try it with your config as well. In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. What is X-Loader? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sat, 20 Oct 2012, Richard Cochran wrote: On Sat, Oct 20, 2012 at 04:27:19PM +, Paul Walmsley wrote: BeagleBone Rev. A6 does not boot v3.7-rc1, at least not for me. I recently posted the missing patches needed to make it work (but the patches are not by me). Those are the patches at: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html ? Yes, that is right. Only the first patch is absoutely required for booting. OK thanks. Also are you using omap2plus_defconfig? Yes, but I de-selected a few items. I will try it again without changing anything. Just tried omap2plus_defconfig here and the board didn't boot, confirming your result. Will add a section to the testlog README.txt about that. In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. What is X-Loader? It's the MLO file on the SD card. The on-chip ROM code boots that. Then X-Loader boots U-Boot. Am not sure if it should still be called X-Loader - in your log it seems to be identifying itself as U-Boot SPL - so maybe that's not the old X-Loader code any more. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sat, Oct 20, 2012 at 06:12:35PM +, Paul Walmsley wrote: Just tried omap2plus_defconfig here and the board didn't boot, confirming your result. Will add a section to the testlog README.txt about that. In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. I tried both omap2plus_defconfig and your am33xx_only config, and neither one work with my (recent) u-boot version. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sat, 20 Oct 2012, Richard Cochran wrote: On Sat, Oct 20, 2012 at 06:12:35PM +, Paul Walmsley wrote: Just tried omap2plus_defconfig here and the board didn't boot, confirming your result. Will add a section to the testlog README.txt about that. In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. I tried both omap2plus_defconfig and your am33xx_only config, and neither one work with my (recent) u-boot version. Just sent you the MLO and u-boot.img from here via private E-mail. Those were the files that came with the BeagleBone SD card here. TI also has a u-boot tree for the AM33xx; might be worth trying: git://arago-project.org/git/projects/u-boot-am33x.git - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ And here's two more. Failing tests: needing investigation Boot tests: * 2420n800: boot hangs during UART initialization - http://lkml.org/lkml/2012/9/11/454 - Various attempts at fixes posted; etiology known; issue still unresolved * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file * 3530ES3 Beagle: I2C timeouts during userspace init - May be related to the threaded IRQ conversion of the I2C driver - Unknown cause PM tests: * 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend - Causes MMC to become unusable since regulators are not reenabled - Can be worked around by reverting the I2C driver conversion to threaded IRQs: - http://marc.info/?l=linux-i2cm=135026587102887w=2 - Appears to be due to an accounting problem; under discussion: - http://marc.info/?l=linux-arm-kernelm=135042360725821w=2 * 3530es3beagle: hangs during off-mode dynamic idle test - Unknown cause; not investigated * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown * 3730 Beagle XM: OPPs do not initialize - Several find_device_opp: Invalid parameters messages appear on boot; related warnings follow - Cause unknown - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi,
On Fri, Oct 19, 2012 at 04:55:38PM +, Paul Walmsley wrote:
On Thu, 18 Oct 2012, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.7-rc1.
Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
And here's two more.
Failing tests: needing investigation
Boot tests:
* 2420n800: boot hangs during UART initialization
- http://lkml.org/lkml/2012/9/11/454
- Various attempts at fixes posted; etiology known; issue still unresolved
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see
http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
* CM-T3517: boot hangs with MMC boot
- Due to missing MMC setup in board file
* 3530ES3 Beagle: I2C timeouts during userspace init
- May be related to the threaded IRQ conversion of the I2C driver
- Unknown cause
Doesn't seem like it's related to threaded IRQ. It says:
[ 23.673858] omap_i2c omap_i2c.1: timeout waiting for bus ready
at that time we didn't even program the transfer yet, meaning we're not
even on wait_for_completion_timeout() inside omap_i2c_xfer_msg(). This
happens before:
static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
{
unsigned long timeout;
timeout = jiffies + OMAP_I2C_TIMEOUT;
while (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) OMAP_I2C_STAT_BB) {
if (time_after(jiffies, timeout)) {
dev_warn(dev-dev, timeout waiting for bus ready\n);
it' stopping here. And that's called...
return -ETIMEDOUT;
}
msleep(1);
}
return 0;
}
[...]
static int
omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
int i;
int r;
r = pm_runtime_get_sync(dev-dev);
if (IS_ERR_VALUE(r))
goto out;
r = omap_i2c_wait_for_bb(dev);
right here. For whatever reason, the bus is kept busy (or at least the
driver thinks so).
Looking closely at the logs I see that definitely I2C was working during
early boot (we managed to mount file system on SD card and twl got
initialized properly). But then we have a long time where I2C isn't
used, so it probably suspended in between.
Then RTC wanted to read a register, I2C woke up, restored context, but
bus was kept busy, for whatever reason.
Does it happen all the time on multiple boots or is it ramdom ?
if (r 0)
goto out;
/*
* When waiting for completion of a i2c transfer, we need to
* set a wake up latency constraint for the MPU. This is to
* ensure quick enough wakeup from idle, when transfer
* completes.
*/
if (dev-latency)
pm_qos_add_request(dev-pm_qos_request,
PM_QOS_CPU_DMA_LATENCY,
dev-latency);
for (i = 0; i num; i++) {
r = omap_i2c_xfer_msg(adap, msgs[i], (i == (num - 1)));
if (r != 0)
break;
}
if (dev-latency)
pm_qos_remove_request(dev-pm_qos_request);
if (r == 0)
r = num;
omap_i2c_wait_for_bb(dev);
out:
pm_runtime_mark_last_busy(dev-dev);
pm_runtime_put_autosuspend(dev-dev);
return r;
}
--
balbi
signature.asc
Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
Hi Felipe,
On Fri, 19 Oct 2012, Felipe Balbi wrote:
On Fri, Oct 19, 2012 at 04:55:38PM +, Paul Walmsley wrote:
On Thu, 18 Oct 2012, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.7-rc1.
Logs and other details at
http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
Failing tests: needing investigation
Boot tests:
* 3530ES3 Beagle: I2C timeouts during userspace init
- May be related to the threaded IRQ conversion of the I2C driver
- Unknown cause
Doesn't seem like it's related to threaded IRQ. It says:
[ 23.673858] omap_i2c omap_i2c.1: timeout waiting for bus ready
at that time we didn't even program the transfer yet, meaning we're not
even on wait_for_completion_timeout() inside omap_i2c_xfer_msg(). This
happens before:
static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
{
unsigned long timeout;
timeout = jiffies + OMAP_I2C_TIMEOUT;
while (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) OMAP_I2C_STAT_BB) {
if (time_after(jiffies, timeout)) {
dev_warn(dev-dev, timeout waiting for bus ready\n);
it' stopping here. And that's called...
return -ETIMEDOUT;
}
msleep(1);
}
return 0;
}
[...]
static int
omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
int i;
int r;
r = pm_runtime_get_sync(dev-dev);
if (IS_ERR_VALUE(r))
goto out;
r = omap_i2c_wait_for_bb(dev);
right here. For whatever reason, the bus is kept busy (or at least the
driver thinks so).
Looking closely at the logs I see that definitely I2C was working during
early boot (we managed to mount file system on SD card and twl got
initialized properly). But then we have a long time where I2C isn't
used, so it probably suspended in between.
Then RTC wanted to read a register, I2C woke up, restored context, but
bus was kept busy, for whatever reason.
Does it happen all the time on multiple boots or is it ramdom ?
Just ran six boot tests here; it occurred in five of them. Then tried
five boot tests on v3.6 and the error didn't show up in any of them.
Abbreviated log at the bottom.
Would be happy to send along a copy of the userspace that was used if it
would be useful to you.
- Paul
paul@nozomi:~$ egrep '(version 3\.|timeout waiting)' 3530es3beagle_log.txt
[0.00] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1
(Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[0.00] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1
(Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[ 22.710418] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 23.726074] omap_i2c omap_i2c.1: timeout waiting for bus ready
[0.00] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1
(Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[ 22.804351] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 23.819976] omap_i2c omap_i2c.1: timeout waiting for bus ready
[0.00] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1
(Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[ 22.805419] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 23.821044] omap_i2c omap_i2c.1: timeout waiting for bus ready
[0.00] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1
(Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[ 22.820648] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 23.836273] omap_i2c omap_i2c.1: timeout waiting for bus ready
[0.00] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1
(Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[ 22.858978] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 23.874603] omap_i2c omap_i2c.1: timeout waiting for bus ready
[0.00] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery
G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012
[0.00] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery
G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012
[0.00] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery
G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012
[0.00] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery
G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012
[0.00] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery
G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi,
On Fri, Oct 19, 2012 at 05:56:48PM +, Paul Walmsley wrote:
Hi Felipe,
On Fri, 19 Oct 2012, Felipe Balbi wrote:
On Fri, Oct 19, 2012 at 04:55:38PM +, Paul Walmsley wrote:
On Thu, 18 Oct 2012, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.7-rc1.
Logs and other details at
http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
Failing tests: needing investigation
Boot tests:
* 3530ES3 Beagle: I2C timeouts during userspace init
- May be related to the threaded IRQ conversion of the I2C driver
- Unknown cause
Doesn't seem like it's related to threaded IRQ. It says:
[ 23.673858] omap_i2c omap_i2c.1: timeout waiting for bus ready
at that time we didn't even program the transfer yet, meaning we're not
even on wait_for_completion_timeout() inside omap_i2c_xfer_msg(). This
happens before:
static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
{
unsigned long timeout;
timeout = jiffies + OMAP_I2C_TIMEOUT;
while (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) OMAP_I2C_STAT_BB) {
if (time_after(jiffies, timeout)) {
dev_warn(dev-dev, timeout waiting for bus ready\n);
it' stopping here. And that's called...
return -ETIMEDOUT;
}
msleep(1);
}
return 0;
}
[...]
static int
omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
int i;
int r;
r = pm_runtime_get_sync(dev-dev);
if (IS_ERR_VALUE(r))
goto out;
r = omap_i2c_wait_for_bb(dev);
right here. For whatever reason, the bus is kept busy (or at least the
driver thinks so).
Looking closely at the logs I see that definitely I2C was working during
early boot (we managed to mount file system on SD card and twl got
initialized properly). But then we have a long time where I2C isn't
used, so it probably suspended in between.
Then RTC wanted to read a register, I2C woke up, restored context, but
bus was kept busy, for whatever reason.
Does it happen all the time on multiple boots or is it ramdom ?
Just ran six boot tests here; it occurred in five of them. Then tried
five boot tests on v3.6 and the error didn't show up in any of them.
Abbreviated log at the bottom.
Would be happy to send along a copy of the userspace that was used if it
would be useful to you.
no need for the userspace, I don't believe it will matter as the problem
happens when RTC is used somehow. I'll see if I can reproduce it here in
any way possible on my beagleXM (different OMAP, I know, but still.
Hopefully I'll trigger it, which means it's not a missing workaround).
cheers
--
balbi
signature.asc
Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
Hi, On Fri, Oct 19, 2012 at 04:55:38PM +, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ And here's two more. [...] * 3530ES3 Beagle: I2C timeouts during userspace init - May be related to the threaded IRQ conversion of the I2C driver - Unknown cause FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c omap_i2c.1: timeout waiting for bus ready). After several reboots they disappered (kernel binary was the same), and I have been unable to reproduce them since. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote: Hi, On Fri, Oct 19, 2012 at 04:55:38PM +, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ And here's two more. [...] * 3530ES3 Beagle: I2C timeouts during userspace init - May be related to the threaded IRQ conversion of the I2C driver - Unknown cause FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c omap_i2c.1: timeout waiting for bus ready). After several reboots they disappered (kernel binary was the same), and I have been unable to reproduce them since. any change you have those logs saved somewhere ? Want to see if it's the same problem triggered by RTC. -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
Hi, On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote: On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote: FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c omap_i2c.1: timeout waiting for bus ready). After several reboots they disappered (kernel binary was the same), and I have been unable to reproduce them since. any change you have those logs saved somewhere ? Want to see if it's the same problem triggered by RTC. I did not save the logs, but now I tried again, I managed to reproduce it after couple boots. The log is below, and after that the there's also one from OK boot for comparison. In the error case, the boot never reaches userspace, just silently hangs (or maybe I just didn't wait enough long). ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.7.0-rc1-n9xx (aaro@blackmetal) (gcc version 4.7.2 (GCC) ) #1 Wed Oct 17 00:28:59 EEST 2012 [0.00] Ignoring unrecognised tag 0x414f4d50 [0.00] Reserving 16777216 bytes SDRAM for VRAM [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [0.00] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz [0.00] Kernel command line: console=tty console=ttyO2,115200 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 239MB = 239MB total [0.00] Memory: 233420k/233420k available, 28724k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc03c (3808 kB) [0.00] .init : 0xc03c - 0xc078569c (3862 kB) [0.00] .data : 0xc0786000 - 0xc07b9880 ( 207 kB) [0.00].bss : 0xc07b98a4 - 0xc08ced10 (1110 kB) [0.00] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] OMAP clocksource: 32k_counter at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] console [tty0] enabled [0.000854] Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) [0.054687] pid_max: default: 32768 minimum: 301 [0.054901] Mount-cache hash table entries: 512 [0.055664] CPU: Testing write buffer coherency: ok [0.056060] Setting up static identity map for 0x802d23e8 - 0x802d2440 [0.057128] devtmpfs: initialized [0.063995] omap_hwmod: mcbsp2: cannot be enabled for reset (3) [0.069488] pinctrl core: initialized pinctrl subsystem [0.070953] regulator-dummy: no parameters [0.071380] NET: Registered protocol family 16 [0.072875] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.073699] omap-gpmc omap-gpmc: GPMC revision 5.0 [0.078308] OMAP GPIO hardware version 2.5 [0.085357] omap_mux_init: Add partition: #1: core, flags: 0 [0.089172] Reprogramming SDRC clock to 33200 Hz [0.095092] hw-breakpoint: debug architecture 0x4 unsupported. [0.100860] Reserving DMA channels 0 and 1 for HS ROM code [0.100891] OMAP DMA hardware revision 4.0 [0.103057] arm-pmu: alias fck already exists [0.121765] bio: create slab bio-0 at 0 [0.160278] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [0.162811] SCSI subsystem initialized [0.163360] usbcore: registered new interface driver usbfs [0.163665] usbcore: registered new interface driver hub [0.164031] usbcore: registered new device driver usb [0.164733] musb-omap2430 musb-omap2430: invalid resource [0.190460] twl 1-0048: PIH (irq 23) chaining IRQs 338..346 [0.190612] twl 1-0048: power (irq 343) chaining IRQs 346..353 [0.191833] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371 [1.203124] omap_i2c omap_i2c.1: timeout waiting for bus ready [2.218749] omap_i2c omap_i2c.1: timeout waiting for bus ready [2.218780] twl: i2c_write failed to transfer all messages [3.234374] omap_i2c omap_i2c.1: timeout waiting for bus ready [3.234405] twl: i2c_write failed to transfer all messages [3.235748] VUSB1V5: 1500 mV normal standby [4.24] omap_i2c omap_i2c.1:
Re: OMAP baseline test results for v3.7-rc1
On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ A few additional observations missing from the original message. Failing tests: needing investigation Boot tests: * 2420n800: boot hangs during UART initialization - http://lkml.org/lkml/2012/9/11/454 - Various attempts at fixes posted; etiology known; issue still unresolved * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file * 4430es2panda: clockevents problems early in boot - boots with dummy_timer - no one-shot mode so no-HZ is likely to fail * 4460pandaes: boot fails early - Appears to be timer-related PM tests: * 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend - Causes MMC to become unusable since regulators are not reenabled - Can be worked around by reverting the I2C driver conversion to threaded IRQs: - http://marc.info/?l=linux-i2cm=135026587102887w=2 - Appears to be due to an accounting problem; under discussion: - http://marc.info/?l=linux-arm-kernelm=135042360725821w=2 * 3530es3beagle: hangs during off-mode dynamic idle test - Unknown cause; not investigated * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown * 4430es2panda: dummy_timer warning messages during resume - Unknown cause; not investigated - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Thu, 2012-10-18 at 06:48 +, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ A few additional observations missing from the original message. Failing tests: needing investigation Boot tests: * 2420n800: boot hangs during UART initialization - http://lkml.org/lkml/2012/9/11/454 - Various attempts at fixes posted; etiology known; issue still unresolved * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file * 4430es2panda: clockevents problems early in boot - boots with dummy_timer - no one-shot mode so no-HZ is likely to fail I have a fix for this problem, however I am seeing this on omap4460 panda. The root cause seems to be that local timer init for OMAP is using wrong interrupt number. It adds a wrong offset to the interrupt (OMAP_INTC_START) which should be omitted. Will send a patch soon along with a new version of core ret set. -Tero * 4460pandaes: boot fails early - Appears to be timer-related PM tests: * 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend - Causes MMC to become unusable since regulators are not reenabled - Can be worked around by reverting the I2C driver conversion to threaded IRQs: - http://marc.info/?l=linux-i2cm=135026587102887w=2 - Appears to be due to an accounting problem; under discussion: - http://marc.info/?l=linux-arm-kernelm=135042360725821w=2 * 3530es3beagle: hangs during off-mode dynamic idle test - Unknown cause; not investigated * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown * 4430es2panda: dummy_timer warning messages during resume - Unknown cause; not investigated - Paul ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Tero, paul, On Thursday 18 October 2012 02:07 PM, Tero Kristo wrote: On Thu, 2012-10-18 at 06:48 +, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ A few additional observations missing from the original message. Failing tests: needing investigation Boot tests: * 2420n800: boot hangs during UART initialization - http://lkml.org/lkml/2012/9/11/454 - Various attempts at fixes posted; etiology known; issue still unresolved * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file * 4430es2panda: clockevents problems early in boot - boots with dummy_timer - no one-shot mode so no-HZ is likely to fail I have a fix for this problem, however I am seeing this on omap4460 panda. The root cause seems to be that local timer init for OMAP is using wrong interrupt number. It adds a wrong offset to the interrupt (OMAP_INTC_START) which should be omitted. Will send a patch soon along with a new version of core ret set. This one is already fixed by [1] and Tony has sent pull request[1] to arm-soc maintainers for 3.7-rc1 which includes the fix. regards santosh [1] https://patchwork.kernel.org/patch/1587621/ [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg78045.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.7-rc1
Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ Changes from previous tests --- Kernel configs have been reorganized and updated. AM335x Beaglebone and OMAP4460 Pandaboard-ES boards have been added to the testbed. Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) Failing tests: fixed by posted patches -- Boot tests: * 2430sdp: vfp_reload_hw oops during MMC initialization - Kernel attempts to save FP registers that don't exist; fix posted: - http://www.spinics.net/lists/arm-kernel/msg200646.html Other: * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control - http://lkml.org/lkml/2012/9/3/265 Failing tests: needing investigation Boot tests: * 2420n800: boot hangs during UART initialization - http://lkml.org/lkml/2012/9/11/454 - Various attempts at fixes posted; etiology known; issue still unresolved * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file PM tests: * 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend - Causes MMC to become unusable since regulators are not reenabled - Can be worked around by reverting the I2C driver conversion to threaded IRQs: - http://marc.info/?l=linux-i2cm=135026587102887w=2 - Appears to be due to an accounting problem; under discussion: - http://marc.info/?l=linux-arm-kernelm=135042360725821w=2 * 3530es3beagle: hangs during off-mode dynamic idle test - Unknown cause; not investigated * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown Kernel size/memory differences -- vmlinux object size (delta in bytes from test_v3.6 (a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)): text data bsstotal kernel +118682 -66688+2280 +54274 am33xx_only +57789 -88928+2148 -28991 n800_multi_omap2xxx +58669 -86432+2180 -25583 n800_only_a +54196+4616 -136 +58676 omap1_defconfig +53420+3096 -104 +56412 omap1_defconfig_1510innovator_only +54384+3112 -168 +57328 omap1_defconfig_5912osk_only +128332 -67728+2144 +62748 omap2plus_defconfig +106894 -83664+1992 +25222 omap2plus_defconfig_2430sdp_only +128296 -67744+2080 +62632 omap2plus_defconfig_cpupm +130151 -67552+1824 +64423 omap2plus_defconfig_no_pm +107810 -88848+1952 +20914 omap2plus_defconfig_omap2_4_only +107293 -88232+2016 +21077 omap2plus_defconfig_omap3_4_only +113921 -66976+2348 +49293 rmk_omap3430_ldp_oldconfig +106849 -47216+2760 +62393 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.6 (a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)) avail rsrvd high freed board kconfig 20k -20k . -152k 2420n800 omap2plus_defconfig -60k60k . 4k 2430sdpomap2plus_defconfig -60k60k . 4k 3517evmomap2plus_defconfig -60k60k . 4k 3530es3beagle omap2plus_defconfig -60k60k . 4k 3730beaglexm omap2plus_defconfig -60k60k . 4k 37xxevmomap2plus_defconfig -60k60k . 4k 4430es2panda omap2plus_defconfig -52k52k . . 5912oskomap2plus_defconfig -60k60k . . cmt3517omap2plus_defconfig - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
