* OMAP baseline test results for v3.7-rc1 @ 2012-10-18 5:20 Paul Walmsley 2012-10-18 6:48 ` Paul Walmsley ` (3 more replies) 0 siblings, 4 replies; 69+ messages in thread From: Paul Walmsley @ 2012-10-18 5:20 UTC (permalink / raw) To: linux-arm-kernel 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-omap&m=134833869730129&w=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-i2c&m=135026587102887&w=2 - Appears to be due to an accounting problem; under discussion: - http://marc.info/?l=linux-arm-kernel&m=135042360725821&w=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 bss total 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 -60k 60k . 4k 2430sdp omap2plus_defconfig -60k 60k . 4k 3517evm omap2plus_defconfig -60k 60k . 4k 3530es3beagle omap2plus_defconfig -60k 60k . 4k 3730beaglexm omap2plus_defconfig -60k 60k . 4k 37xxevm omap2plus_defconfig -60k 60k . 4k 4430es2panda omap2plus_defconfig -52k 52k . . 5912osk omap2plus_defconfig -60k 60k . . cmt3517 omap2plus_defconfig - Paul ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-18 5:20 OMAP baseline test results for v3.7-rc1 Paul Walmsley @ 2012-10-18 6:48 ` Paul Walmsley 2012-10-18 8:37 ` Tero Kristo 2012-10-19 16:55 ` Paul Walmsley ` (2 subsequent siblings) 3 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-18 6:48 UTC (permalink / raw) To: linux-arm-kernel 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-omap&m=134833869730129&w=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-i2c&m=135026587102887&w=2 > - Appears to be due to an accounting problem; under discussion: > - http://marc.info/?l=linux-arm-kernel&m=135042360725821&w=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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-18 6:48 ` Paul Walmsley @ 2012-10-18 8:37 ` Tero Kristo 2012-10-18 8:48 ` Santosh Shilimkar 0 siblings, 1 reply; 69+ messages in thread From: Tero Kristo @ 2012-10-18 8:37 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2012-10-18 at 06:48 +0000, 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-omap&m=134833869730129&w=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-i2c&m=135026587102887&w=2 > > - Appears to be due to an accounting problem; under discussion: > > - http://marc.info/?l=linux-arm-kernel&m=135042360725821&w=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-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-18 8:37 ` Tero Kristo @ 2012-10-18 8:48 ` Santosh Shilimkar 2012-10-20 17:30 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Santosh Shilimkar @ 2012-10-18 8:48 UTC (permalink / raw) To: linux-arm-kernel Tero, paul, On Thursday 18 October 2012 02:07 PM, Tero Kristo wrote: > On Thu, 2012-10-18 at 06:48 +0000, 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-omap&m=134833869730129&w=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 at vger.kernel.org/msg78045.html ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-18 8:48 ` Santosh Shilimkar @ 2012-10-20 17:30 ` Paul Walmsley 0 siblings, 0 replies; 69+ messages in thread From: Paul Walmsley @ 2012-10-20 17:30 UTC (permalink / raw) To: linux-arm-kernel 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 +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-18 5:20 OMAP baseline test results for v3.7-rc1 Paul Walmsley 2012-10-18 6:48 ` Paul Walmsley @ 2012-10-19 16:55 ` Paul Walmsley 2012-10-19 17:01 ` Felipe Balbi ` (3 more replies) 2012-10-20 14:11 ` Richard Cochran 2012-10-20 17:20 ` Paul Walmsley 3 siblings, 4 replies; 69+ messages in thread From: Paul Walmsley @ 2012-10-19 16:55 UTC (permalink / raw) To: linux-arm-kernel 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-omap&m=134833869730129&w=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-i2c&m=135026587102887&w=2 > - Appears to be due to an accounting problem; under discussion: > - http://marc.info/?l=linux-arm-kernel&m=135042360725821&w=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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-19 16:55 ` Paul Walmsley @ 2012-10-19 17:01 ` Felipe Balbi 2012-10-19 17:56 ` Paul Walmsley 2012-10-19 19:03 ` Aaro Koskinen ` (2 subsequent siblings) 3 siblings, 1 reply; 69+ messages in thread From: Felipe Balbi @ 2012-10-19 17:01 UTC (permalink / raw) To: linux-arm-kernel Hi, On Fri, Oct 19, 2012 at 04:55:38PM +0000, 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-omap&m=134833869730129&w=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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121019/21c960e3/attachment.sig> ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-19 17:01 ` Felipe Balbi @ 2012-10-19 17:56 ` Paul Walmsley 2012-10-19 18:10 ` Felipe Balbi 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-19 17:56 UTC (permalink / raw) To: linux-arm-kernel Hi Felipe, On Fri, 19 Oct 2012, Felipe Balbi wrote: > On Fri, Oct 19, 2012 at 04:55:38PM +0000, 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 at nozomi:~$ egrep '(version 3\.|timeout waiting)' 3530es3beagle_log.txt [ 0.000000] Linux version 3.7.0-rc1 (paul at nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012 [ 0.000000] Linux version 3.7.0-rc1 (paul at 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.000000] Linux version 3.7.0-rc1 (paul at 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.000000] Linux version 3.7.0-rc1 (paul at 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.000000] Linux version 3.7.0-rc1 (paul at 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.000000] Linux version 3.7.0-rc1 (paul at 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.000000] Linux version 3.6.0 (paul at nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012 [ 0.000000] Linux version 3.6.0 (paul at nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012 [ 0.000000] Linux version 3.6.0 (paul at nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012 [ 0.000000] Linux version 3.6.0 (paul at nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012 [ 0.000000] Linux version 3.6.0 (paul at nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-19 17:56 ` Paul Walmsley @ 2012-10-19 18:10 ` Felipe Balbi 0 siblings, 0 replies; 69+ messages in thread From: Felipe Balbi @ 2012-10-19 18:10 UTC (permalink / raw) To: linux-arm-kernel Hi, On Fri, Oct 19, 2012 at 05:56:48PM +0000, Paul Walmsley wrote: > Hi Felipe, > > On Fri, 19 Oct 2012, Felipe Balbi wrote: > > > On Fri, Oct 19, 2012 at 04:55:38PM +0000, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121019/6b962a95/attachment.sig> ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-19 16:55 ` Paul Walmsley 2012-10-19 17:01 ` Felipe Balbi @ 2012-10-19 19:03 ` Aaro Koskinen 2012-10-19 19:01 ` Felipe Balbi 2012-10-20 6:14 ` Paul Walmsley 2012-10-20 6:24 ` Paul Walmsley 3 siblings, 1 reply; 69+ messages in thread From: Aaro Koskinen @ 2012-10-19 19:03 UTC (permalink / raw) To: linux-arm-kernel Hi, On Fri, Oct 19, 2012 at 04:55:38PM +0000, 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-19 19:03 ` Aaro Koskinen @ 2012-10-19 19:01 ` Felipe Balbi 2012-10-19 19:38 ` Aaro Koskinen 0 siblings, 1 reply; 69+ messages in thread From: Felipe Balbi @ 2012-10-19 19:01 UTC (permalink / raw) To: linux-arm-kernel On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote: > Hi, > > On Fri, Oct 19, 2012 at 04:55:38PM +0000, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121019/0b494aa5/attachment-0001.sig> ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-19 19:01 ` Felipe Balbi @ 2012-10-19 19:38 ` Aaro Koskinen 2012-10-22 17:21 ` Kevin Hilman 0 siblings, 1 reply; 69+ messages in thread From: Aaro Koskinen @ 2012-10-19 19:38 UTC (permalink / raw) To: linux-arm-kernel 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.000000] Booting Linux on physical CPU 0 [ 0.000000] Linux version 3.7.0-rc1-n9xx (aaro at blackmetal) (gcc version 4.7.2 (GCC) ) #1 Wed Oct 17 00:28:59 EEST 2012 [ 0.000000] Ignoring unrecognised tag 0x414f4d50 [ 0.000000] Reserving 16777216 bytes SDRAM for VRAM [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [ 0.000000] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz [ 0.000000] Kernel command line: console=tty console=ttyO2,115200 [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 239MB = 239MB total [ 0.000000] Memory: 233420k/233420k available, 28724k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc03c0000 (3808 kB) [ 0.000000] .init : 0xc03c0000 - 0xc078569c (3862 kB) [ 0.000000] .data : 0xc0786000 - 0xc07b9880 ( 207 kB) [ 0.000000] .bss : 0xc07b98a4 - 0xc08ced10 (1110 kB) [ 0.000000] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts [ 0.000000] Total of 96 interrupts on 1 active controller [ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] 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 332000000 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.249999] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 4.250030] twl: i2c_write failed to transfer all messages [ 4.250701] VUSB1V8: 1800 mV normal standby [ 5.265624] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 5.265655] twl: i2c_write failed to transfer all messages [ 5.266296] VUSB3V1: 3100 mV normal standby [ 6.281249] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 6.281280] twl: i2c_write failed to transfer all messages [ 7.296874] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 7.296905] twl: i2c_write failed to transfer all messages [ 8.312499] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 8.312530] twl: i2c_write failed to transfer all messages [ 9.328124] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 9.328155] twl: i2c_write failed to transfer all messages [ 10.343749] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 10.343780] twl: i2c_write failed to transfer all messages [ 11.359374] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 11.359405] twl: i2c_write failed to transfer all messages [ 12.374999] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 12.375030] twl: i2c_write failed to transfer all messages [ 13.390624] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 13.390655] twl: i2c_write failed to transfer all messages [ 14.406249] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 14.406280] twl: i2c_write failed to transfer all messages [ 15.421874] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 15.421905] twl: i2c_write failed to transfer all messages [ 16.437499] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 16.437530] twl: i2c_write failed to transfer all messages [ 17.453124] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 17.453155] twl: i2c_write failed to transfer all messages [ 17.453186] twl4030: twl4030_sih_bus_sync_unlock, write --> -110 [ 18.468749] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 18.468780] twl: i2c_read failed to transfer all messages [ 18.468811] twl4030: twl4030_sih_bus_sync_unlock, read --> -110 [ 19.484374] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 19.484405] twl: i2c_read failed to transfer all messages [ 19.484466] twl4030_usb twl4030_usb: USB link status err -110 [ 19.484497] twl4030_usb twl4030_usb: Initialized TWL4030 USB module [ 20.499999] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 20.500030] twl: i2c_read failed to transfer all messages [ 21.515624] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 21.515655] twl: i2c_write failed to transfer all messages [ 21.515686] VPLL: failed to apply 1800000uV constraint [ 21.516021] twl_reg twl_reg.4: can't register VPLL1, -110 [ 21.516052] twl_reg: probe of twl_reg.4 failed with error -110 [ 22.531249] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 22.531280] twl: i2c_read failed to transfer all messages [ 22.531311] VIO: failed to enable [ 22.531616] twl_reg twl_reg.2: can't register VIO, -110 [ 22.531646] twl_reg: probe of twl_reg.2 failed with error -110 [ 22.532287] vdd_mpu_iva: 600 <--> 1450 mV normal [ 23.546874] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 23.546905] twl: i2c_write failed to transfer all messages [ 23.547546] vdd_core: 600 <--> 1450 mV normal [ 24.562499] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 24.562530] twl: i2c_write failed to transfer all messages [ 25.578124] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 25.578155] twl: i2c_read failed to transfer all messages [ 25.578186] VMMC1: 1850 <--> 3150 mV normal standby [ 26.593749] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 26.593780] twl: i2c_read failed to transfer all messages [ 27.609374] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 27.609405] twl: i2c_write failed to transfer all messages [ 28.624999] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 28.625030] twl: i2c_read failed to transfer all messages [ 29.640624] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 29.640655] twl: i2c_write failed to transfer all messages [ 29.640686] VDAC: failed to apply 1800000uV constraint [ 29.640991] twl_reg twl_reg.3: can't register VDAC, -110 [ 29.641021] twl_reg: probe of twl_reg.3 failed with error -110 [ 29.641662] VCSI: 1800 mV normal standby [ 30.656249] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 30.656280] twl: i2c_read failed to transfer all messages [ 31.671874] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 31.671905] twl: i2c_write failed to transfer all messages [ 32.687499] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 32.687530] twl: i2c_read failed to transfer all messages [ 32.687561] VINTANA1: failed to enable [ 32.687835] twl_reg twl_reg.14: can't register VINTANA1, -110 [ 32.687896] twl_reg: probe of twl_reg.14 failed with error -110 [ 33.703124] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 33.703155] twl: i2c_read failed to transfer all messages [ 34.718749] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 34.718780] twl: i2c_write failed to transfer all messages [ 34.718811] VINTANA2: failed to apply 2750000uV constraint [ 34.719085] twl_reg twl_reg.15: can't register VINTANA2, -110 [ 34.719146] twl_reg: probe of twl_reg.15 failed with error -110 [ 35.734374] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 35.734405] twl: i2c_read failed to transfer all messages [ 35.734436] VINTDIG: failed to enable [ 35.734710] twl_reg twl_reg.16: can't register VINTDIG, -110 [ 35.734771] twl_reg: probe of twl_reg.16 failed with error -110 [ 36.749999] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 36.750030] twl: i2c_read failed to transfer all messages [ 37.765624] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 37.765655] twl: i2c_write failed to transfer all messages [ 37.765686] VSDI_CSI: failed to apply 1800000uV constraint [ 37.765960] twl_reg twl_reg.5: can't register VPLL2, -110 [ 37.766021] twl_reg: probe of twl_reg.5 failed with error -110 [ 38.781249] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 38.781280] twl: i2c_read failed to transfer all messages [ 38.781311] V28_A: failed to enable [ 38.781585] twl_reg twl_reg.7: can't register VMMC2, -110 [ 38.781646] twl_reg: probe of twl_reg.7 failed with error -110 [ 39.796874] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 39.796905] twl: i2c_read failed to transfer all messages [ 40.812499] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 40.812530] twl: i2c_write failed to transfer all messages [ 40.812561] VMMC2_IO_18: failed to apply 1800000uV constraint [ 40.812835] twl_reg twl_reg.8: can't register VSIM, -110 [ 40.812896] twl_reg: probe of twl_reg.8 failed with error -110 [ 41.828124] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 41.828155] twl: i2c_read failed to transfer all messages [ 41.828186] V28: failed to enable [ 41.828460] twl_reg twl_reg.9: can't register VAUX1, -110 [ 41.828521] twl_reg: probe of twl_reg.9 failed with error -110 [ 42.843749] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 42.843780] twl: i2c_read failed to transfer all messages [ 42.843811] VMMC2_30: 2800 <--> 3000 mV normal standby [ 43.859374] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 43.859405] twl: i2c_read failed to transfer all messages [ 44.874999] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 44.875030] twl: i2c_write failed to transfer all messages [ 45.890624] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 45.890655] twl: i2c_read failed to transfer all messages [ 46.906249] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 46.906280] twl: i2c_write failed to transfer all messages [ 46.906311] VCAM_ANA_28: failed to apply 2800000uV constraint [ 46.906585] twl_reg twl_reg.13: can't register VAUX4, -110 [ 46.906646] twl_reg: probe of twl_reg.13 failed with error -110 [ 46.906707] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 2200 kHz [ 46.908630] omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 100 kHz [ 46.909271] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz [ 46.912200] Switching to clocksource 32k_counter [ 46.938690] NET: Registered protocol family 2 [ 46.939422] TCP established hash table entries: 8192 (order: 4, 65536 bytes) [ 46.939666] TCP bind hash table entries: 8192 (order: 3, 32768 bytes) [ 46.939819] TCP: Hash tables configured (established 8192 bind 8192) [ 46.939971] TCP: reno registered [ 46.940032] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 46.940063] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 46.984313] CPU PMU: probing PMU on CPU 0 [ 46.984374] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available [ 47.340698] msgmni has been set to 455 [ 47.349639] io scheduler noop registered [ 47.350799] io scheduler cfq registered (default) [ 47.371429] OMAP DSS rev 2.0 [ 47.382049] omapdss SDI error: can't get VDDS_SDI regulator [ 47.382110] omapdss SDI error: device lcd init failed: -517 [ 47.392883] omapdss VENC error: can't get VDDA_DAC regulator [ 47.392944] omapdss VENC error: device tv init failed: -517 [ 47.403137] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 47.438934] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0 [ 47.443847] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1 [ 47.450317] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2 [ 48.737792] console [ttyO2] enabled [ 48.777343] mtdoops: mtd device (mtddev=name/number) must be supplied [ 48.793426] OneNAND driver initializing [ 48.798004] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x04000000, virtual base d0880000, freq 66 MHz [ 48.809417] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [ 48.814514] OneNAND version = 0x0121 [ 48.820068] Scanning device for bad blocks [ 48.903167] OneNAND eraseblock 1229 is an initial bad block [ 48.965820] Creating 6 MTD partitions on "omap2-onenand": [ 48.971679] 0x000000000000-0x000000020000 : "bootloader" [ 48.994049] 0x000000020000-0x000000080000 : "config" [ 49.020263] 0x000000080000-0x0000000c0000 : "log" [ 49.046173] 0x0000000c0000-0x0000002c0000 : "kernel" [ 49.072509] 0x0000002c0000-0x0000004c0000 : "initfs" [ 49.098693] 0x0000004c0000-0x000010000000 : "rootfs" [ 49.140594] omap-dma-engine omap-dma-engine: allocating channel for 40 [ 49.147644] omap-dma-engine omap-dma-engine: allocating channel for 39 [ 49.159637] omap-dma-engine omap-dma-engine: allocating channel for 36 [ 49.166656] omap-dma-engine omap-dma-engine: allocating channel for 35 [ 49.193847] omap-dma-engine omap-dma-engine: allocating channel for 71 [ 49.200805] omap-dma-engine omap-dma-engine: allocating channel for 70 [ 49.214599] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) [ 49.245239] mousedev: PS/2 mouse device common for all mice [ 49.261505] input: TWL4030 Keypad as /devices/platform/omap_i2c.1/i2c-1/1-004a/twl4030_keypad/input/input0 [ 49.298553] input: TSC2005 touchscreen as /devices/platform/omap2_mcspi.1/spi_master/spi1/spi1.0/input/input1 The good case: Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0 [ 0.000000] Linux version 3.7.0-rc1-n9xx (aaro at blackmetal) (gcc version 4.7.2 (GCC) ) #1 Wed Oct 17 00:28:59 EEST 2012 [ 0.000000] Ignoring unrecognised tag 0x414f4d50 [ 0.000000] Reserving 16777216 bytes SDRAM for VRAM [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [ 0.000000] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz [ 0.000000] Kernel command line: console=tty console=ttyO2,115200 [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 239MB = 239MB total [ 0.000000] Memory: 233420k/233420k available, 28724k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc03c0000 (3808 kB) [ 0.000000] .init : 0xc03c0000 - 0xc078569c (3862 kB) [ 0.000000] .data : 0xc0786000 - 0xc07b9880 ( 207 kB) [ 0.000000] .bss : 0xc07b98a4 - 0xc08ced10 (1110 kB) [ 0.000000] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts [ 0.000000] Total of 96 interrupts on 1 active controller [ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] console [tty0] enabled [ 0.000823] Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) [ 0.054656] pid_max: default: 32768 minimum: 301 [ 0.054870] Mount-cache hash table entries: 512 [ 0.055633] 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.067474] pinctrl core: initialized pinctrl subsystem [ 0.068878] regulator-dummy: no parameters [ 0.069305] NET: Registered protocol family 16 [ 0.070831] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.071685] omap-gpmc omap-gpmc: GPMC revision 5.0 [ 0.076263] OMAP GPIO hardware version 2.5 [ 0.083374] omap_mux_init: Add partition: #1: core, flags: 0 [ 0.087158] Reprogramming SDRC clock to 332000000 Hz [ 0.092987] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.098846] Reserving DMA channels 0 and 1 for HS ROM code [ 0.098907] OMAP DMA hardware revision 4.0 [ 0.101013] arm-pmu: alias fck already exists [ 0.119781] bio: create slab <bio-0> at 0 [ 0.158294] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.160827] SCSI subsystem initialized [ 0.161407] usbcore: registered new interface driver usbfs [ 0.161682] usbcore: registered new interface driver hub [ 0.162017] usbcore: registered new device driver usb [ 0.162689] musb-omap2430 musb-omap2430: invalid resource [ 0.188476] twl 1-0048: PIH (irq 23) chaining IRQs 338..346 [ 0.188659] twl 1-0048: power (irq 343) chaining IRQs 346..353 [ 0.189849] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371 [ 0.192382] VUSB1V5: 1500 mV normal standby [ 0.193176] VUSB1V8: 1800 mV normal standby [ 0.193969] VUSB3V1: 3100 mV normal standby [ 0.198425] musb-omap2430 musb-omap2430: musb core is not yet ready [ 0.198486] twl4030_usb twl4030_usb: Initialized TWL4030 USB module [ 0.200286] VPLL: 1800 mV normal standby [ 0.201354] VIO: 1800 mV normal standby [ 0.202239] vdd_mpu_iva: 600 <--> 1450 mV normal [ 0.203033] vdd_core: 600 <--> 1450 mV normal [ 0.203979] VMMC1: 1850 <--> 3150 mV at 3000 mV normal standby [ 0.205139] VDAC: 1800 mV normal standby [ 0.206024] VCSI: 1800 mV normal standby [ 0.207122] VINTANA1: 1500 mV normal standby [ 0.208404] VINTANA2: 2750 mV normal standby [ 0.209503] VINTDIG: 1500 mV normal standby [ 0.210754] VSDI_CSI: 1800 mV normal standby [ 0.211975] V28_A: 2800 <--> 3000 mV at 2600 mV normal standby [ 0.213195] VMMC2_IO_18: 1800 mV normal standby [ 0.214294] V28: 2800 mV normal standby [ 0.215332] VMMC2_30: 2800 <--> 3000 mV at 2800 mV normal standby [ 0.216552] VCAM_ANA_28: 2800 mV normal standby [ 0.216857] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 2200 kHz [ 0.218841] omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 100 kHz [ 0.219543] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz [ 0.222442] Switching to clocksource 32k_counter [ 0.248962] NET: Registered protocol family 2 [ 0.249725] TCP established hash table entries: 8192 (order: 4, 65536 bytes) [ 0.250000] TCP bind hash table entries: 8192 (order: 3, 32768 bytes) [ 0.250152] TCP: Hash tables configured (established 8192 bind 8192) [ 0.250305] TCP: reno registered [ 0.250335] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 0.250396] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 0.294677] CPU PMU: probing PMU on CPU 0 [ 0.294769] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available [ 0.650421] msgmni has been set to 455 [ 0.659210] io scheduler noop registered [ 0.660369] io scheduler cfq registered (default) [ 0.681091] OMAP DSS rev 2.0 [ 0.722259] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 0.757598] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0 [ 0.763275] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1 [ 0.768859] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2 [ 1.345886] console [ttyO2] enabled [ 1.385345] mtdoops: mtd device (mtddev=name/number) must be supplied [ 1.401428] OneNAND driver initializing [ 1.405975] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x04000000, virtual base d0880000, freq 66 MHz [ 1.417388] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [ 1.422485] OneNAND version = 0x0121 [ 1.428039] Scanning device for bad blocks [ 1.510833] OneNAND eraseblock 1229 is an initial bad block [ 1.573272] Creating 6 MTD partitions on "omap2-onenand": [ 1.579101] 0x000000000000-0x000000020000 : "bootloader" [ 1.601562] 0x000000020000-0x000000080000 : "config" [ 1.627746] 0x000000080000-0x0000000c0000 : "log" [ 1.653228] 0x0000000c0000-0x0000002c0000 : "kernel" [ 1.679840] 0x0000002c0000-0x0000004c0000 : "initfs" [ 1.705993] 0x0000004c0000-0x000010000000 : "rootfs" [ 1.747772] omap-dma-engine omap-dma-engine: allocating channel for 40 [ 1.754791] omap-dma-engine omap-dma-engine: allocating channel for 39 [ 1.766784] omap-dma-engine omap-dma-engine: allocating channel for 36 [ 1.773803] omap-dma-engine omap-dma-engine: allocating channel for 35 [ 1.800994] omap-dma-engine omap-dma-engine: allocating channel for 71 [ 1.807983] omap-dma-engine omap-dma-engine: allocating channel for 70 [ 1.821685] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) [ 1.850494] mousedev: PS/2 mouse device common for all mice [ 1.866729] input: TWL4030 Keypad as /devices/platform/omap_i2c.1/i2c-1/1-004a/twl4030_keypad/input/input0 [ 1.903717] input: TSC2005 touchscreen as /devices/platform/omap2_mcspi.1/spi_master/spi1/spi1.0/input/input1 [ 1.935546] input: twl4030_pwrbutton as /devices/platform/omap_i2c.1/i2c-1/1-0049/twl4030_pwrbutton/input/input2 [ 1.957153] twl_rtc twl_rtc: Enabling TWL-RTC [ 1.974426] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 [ 1.986541] i2c /dev entries driver [ 2.010467] Driver for 1-wire Dallas network protocol. [ 2.041320] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec [ 2.058074] twl4030_wdt twl4030_wdt: Failed to register misc device [ 2.064819] twl4030_wdt: probe of twl4030_wdt failed with error -16 [ 2.087432] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk [ 2.093872] omap-dma-engine omap-dma-engine: allocating channel for 62 [ 2.100860] omap-dma-engine omap-dma-engine: allocating channel for 61 [ 2.324615] omap_hsmmc omap_hsmmc.0: mmc0: cover is open, card is now inaccessible [ 2.488739] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk [ 2.495086] omap-dma-engine omap-dma-engine: allocating channel for 48 [ 2.502075] omap-dma-engine omap-dma-engine: allocating channel for 47 [ 2.574462] usbcore: registered new interface driver usbhid [ 2.580383] usbhid: USB HID core driver [ 2.594512] oprofile: using arm/armv7 [ 2.598815] TCP: cubic registered [ 2.602355] NET: Registered protocol family 17 [ 2.607177] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 [ 2.626220] ThumbEE CPU extension supported. [ 2.630889] clock: disabling unused clocks to save power [ 2.650207] VCSI: disabling [ 2.676544] input: gpio-keys as /devices/platform/gpio-keys/input/input3 [ 2.696746] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:12 UTC (946684812) [ 2.716003] Freeing init memory: 3860K [ 2.848114] acx565akm spi1.2: omapfb: acx565akm rev 8a LCD detected [ 2.868896] mmc1: new high speed MMC card at address 0001 [ 2.894683] mmcblk0: mmc1:0001 MMC32G 29.8 GiB [ 2.902282] mmcblk0boot0: mmc1:0001 MMC32G partition 1 512 KiB [ 2.923126] mmcblk0boot1: mmc1:0001 MMC32G partition 2 512 KiB [ 2.947784] mmcblk0: p1 p2 p3 [ 2.952819] Console: switching to colour frame buffer device 100x30 [ 2.994689] mmcblk0boot1: unknown partition table [ 3.020538] mmcblk0boot0: unknown partition table [ 3.120727] gadget: using random self ethernet address [ 3.129394] gadget: using random host ethernet address [ 3.148956] usb0: MAC a6:c2:85:ce:e5:0b [ 3.155944] usb0: HOST MAC ee:48:89:41:f9:74 [ 3.163299] gadget: Ethernet Gadget, version: Memorial Day 2008 [ 3.172271] gadget: g_ether ready [ 3.190399] musb-hdrc musb-hdrc.0: MUSB HDRC host driver [ 3.198913] musb-hdrc musb-hdrc.0: new USB bus registered, assigned bus number 1 [ 3.209655] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.219604] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.230041] usb usb1: Product: MUSB HDRC host driver [ 3.238067] usb usb1: Manufacturer: Linux 3.7.0-rc1-n9xx musb-hcd [ 3.247283] usb usb1: SerialNumber: musb-hdrc.0 [ 3.261840] hub 1-0:1.0: USB hub found [ 3.268707] hub 1-0:1.0: 1 port detected [719] Jan 01 00:00:13 Not backgrounding [ 3.706481] gadget: high-speed config #1: CDC Ethernet (ECM) A. ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-19 19:38 ` Aaro Koskinen @ 2012-10-22 17:21 ` Kevin Hilman 2012-10-22 20:43 ` Kevin Hilman 0 siblings, 1 reply; 69+ messages in thread From: Kevin Hilman @ 2012-10-22 17:21 UTC (permalink / raw) To: linux-arm-kernel Aaro Koskinen <aaro.koskinen@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-22 17:21 ` Kevin Hilman @ 2012-10-22 20:43 ` Kevin Hilman 0 siblings, 0 replies; 69+ messages in thread From: Kevin Hilman @ 2012-10-22 20:43 UTC (permalink / raw) To: linux-arm-kernel Kevin Hilman <khilman@deeprootsystems.com> writes: > Aaro Koskinen <aaro.koskinen@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-19 16:55 ` Paul Walmsley 2012-10-19 17:01 ` Felipe Balbi 2012-10-19 19:03 ` Aaro Koskinen @ 2012-10-20 6:14 ` Paul Walmsley 2012-10-22 16:12 ` Jean Pihet 2012-10-20 6:24 ` Paul Walmsley 3 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-20 6:14 UTC (permalink / raw) To: linux-arm-kernel 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.pihet@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 6:14 ` Paul Walmsley @ 2012-10-22 16:12 ` Jean Pihet 2012-10-22 17:26 ` Jean Pihet ` (2 more replies) 0 siblings, 3 replies; 69+ messages in thread From: Jean Pihet @ 2012-10-22 16:12 UTC (permalink / raw) To: linux-arm-kernel Hi, On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley <paul@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.pihet@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-22 16:12 ` Jean Pihet @ 2012-10-22 17:26 ` Jean Pihet 2012-10-23 19:19 ` Paul Walmsley 2012-10-23 19:17 ` Kevin Hilman 2012-10-23 19:18 ` Paul Walmsley 2 siblings, 1 reply; 69+ messages in thread From: Jean Pihet @ 2012-10-22 17:26 UTC (permalink / raw) To: linux-arm-kernel On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote: > Hi, > > On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley <paul@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.pihet@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-22 17:26 ` Jean Pihet @ 2012-10-23 19:19 ` Paul Walmsley 2012-10-23 19:23 ` Jean Pihet 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-23 19:19 UTC (permalink / raw) To: linux-arm-kernel On Mon, 22 Oct 2012, Jean Pihet wrote: > On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet <jean.pihet@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-23 19:19 ` Paul Walmsley @ 2012-10-23 19:23 ` Jean Pihet 2012-10-25 10:12 ` Felipe Balbi 2012-10-30 4:16 ` Paul Walmsley 0 siblings, 2 replies; 69+ messages in thread From: Jean Pihet @ 2012-10-23 19:23 UTC (permalink / raw) To: linux-arm-kernel On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley <paul@pwsan.com> wrote: > On Mon, 22 Oct 2012, Jean Pihet wrote: > >> On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet <jean.pihet@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-23 19:23 ` Jean Pihet @ 2012-10-25 10:12 ` Felipe Balbi 2012-10-26 20:15 ` Felipe Balbi 2012-10-30 4:16 ` Paul Walmsley 1 sibling, 1 reply; 69+ messages in thread From: Felipe Balbi @ 2012-10-25 10:12 UTC (permalink / raw) To: linux-arm-kernel 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 <paul@pwsan.com> wrote: > > On Mon, 22 Oct 2012, Jean Pihet wrote: > > > >> On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet <jean.pihet@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-omap&m=135115602407925&w=2 -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121025/75fc7df8/attachment-0001.sig> ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-25 10:12 ` Felipe Balbi @ 2012-10-26 20:15 ` Felipe Balbi 2012-10-26 22:03 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Felipe Balbi @ 2012-10-26 20:15 UTC (permalink / raw) To: linux-arm-kernel 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 <paul@pwsan.com> wrote: > > > On Mon, 22 Oct 2012, Jean Pihet wrote: > > > > > >> On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet <jean.pihet@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-omap&m=135115602407925&w=2 ping -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/fb79736f/attachment-0001.sig> ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-26 20:15 ` Felipe Balbi @ 2012-10-26 22:03 ` Paul Walmsley 2012-10-29 20:00 ` Felipe Balbi 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-26 22:03 UTC (permalink / raw) To: linux-arm-kernel 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 <paul@pwsan.com> wrote: > > > > On Mon, 22 Oct 2012, Jean Pihet wrote: > > > > > > > >> On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet <jean.pihet@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-omap&m=135115602407925&w=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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-26 22:03 ` Paul Walmsley @ 2012-10-29 20:00 ` Felipe Balbi 2012-10-30 12:17 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Felipe Balbi @ 2012-10-29 20:00 UTC (permalink / raw) To: linux-arm-kernel Hi, On Fri, Oct 26, 2012 at 10:03:11PM +0000, 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 <paul@pwsan.com> wrote: > > > > > On Mon, 22 Oct 2012, Jean Pihet wrote: > > > > > > > > > >> On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet <jean.pihet@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-omap&m=135115602407925&w=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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121029/c02377b7/attachment-0001.sig> ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-29 20:00 ` Felipe Balbi @ 2012-10-30 12:17 ` Paul Walmsley 2012-10-30 12:32 ` Felipe Balbi 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-30 12:17 UTC (permalink / raw) To: linux-arm-kernel 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. - Paul U-Boot 2011.06-dirty (Sep 04 2012 - 17:06:58) OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 In: serial Out: serial Err: serial Beagle Rev C1/C2/C3 timed out in wait_for_pin: I2C_STAT=0 I2C read: I/O error Unrecognized expansion board: 0 Die ID #5cf200030000000004013f7902012010 Hit any key to stop autoboot: 2 \b\b\b 0 OMAP3 beagleboard.org # OMAP3 beagleboard.org # OMAP3 beagleboard.org # setenv bootargs console=ttyO2,230400n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait OMAP3 beagleboard.org # setenv bootargs console=ttyO2,230400n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait debug ignore_loglevel OMAP3 beagleboard.org # loady ## Ready for binary (ymodem) download to 0x80200000 at 230400 bps... CModem - CRC mode, 32426(SOH)/0(STX)/0(CAN) packets, 5 retries ## Total Size = 0x003f53f0 = 4150256 Bytes OMAP3 beagleboard.org # bootm ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux-3.7.0-rc3 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4150192 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.000000] Booting Linux on physical CPU 0 [ 0.000000] Linux version 3.7.0-rc3 (paul at dusk) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #703 SMP Tue Oct 30 05:56:54 MDT 2012 [ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] Machine: OMAP3 Beagle Board [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] On node 0 totalpages: 65280 [ 0.000000] free_area_init_node: node 0, pgdat c07de400, node_mem_map c0d3c000 [ 0.000000] Normal zone: 512 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 64768 pages, LIFO batch:15 [ 0.000000] OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp ) [ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [ 0.000000] PERCPU: Embedded 9 pages/cpu @c0f42000 s12928 r8192 d15744 u36864 [ 0.000000] pcpu-alloc: s12928 r8192 d15744 u36864 alloc=9*4096 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [ 0.000000] Kernel command line: console=ttyO2,230400n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait debug ignore_loglevel [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 255MB = 255MB total [ 0.000000] Memory: 245256k/245256k available, 16888k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc07047fc (7154 kB) [ 0.000000] .init : 0xc0705000 - 0xc0755280 ( 321 kB) [ 0.000000] .data : 0xc0756000 - 0xc07e15e0 ( 558 kB) [ 0.000000] .bss : 0xc07e1604 - 0xc0d3bfac (5483 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts [ 0.000000] Total of 96 interrupts on 1 active controller [ 0.000000] OMAP clockevent source: GPTIMER12 at 32768 Hz [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 [ 0.000000] ... CHAINHASH_SIZE: 16384 [ 0.000000] memory used by lock dependency info: 3695 kB [ 0.000000] per task-struct memory footprint: 1152 bytes [ 0.001220] Calibrating delay loop... 313.50 BogoMIPS (lpj=1222656) [ 0.103363] pid_max: default: 32768 minimum: 301 [ 0.104187] Security Framework initialized [ 0.104431] Mount-cache hash table entries: 512 [ 0.110626] CPU: Testing write buffer coherency: ok [ 0.111907] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [ 0.112030] Setting up static identity map for 0x8051f158 - 0x8051f1c8 [ 0.115997] Brought up 1 CPUs [ 0.116027] SMP: Total of 1 processors activated (313.50 BogoMIPS). [ 0.132202] ttyO2 used as console in debug mode: uart2 clocks will not be gated [ 0.139984] pinctrl core: initialized pinctrl subsystem [ 0.148834] regulator-dummy: no parameters [ 0.151702] NET: Registered protocol family 16 [ 0.153503] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.156249] omap-gpmc omap-gpmc: GPMC revision 5.0 [ 0.173187] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [ 0.173919] OMAP GPIO hardware version 2.5 [ 0.177062] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [ 0.180633] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [ 0.183898] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [ 0.187469] gpiochip_add: registered GPIOs 128 to 159 on device: gpio [ 0.190551] gpiochip_add: registered GPIOs 160 to 191 on device: gpio [ 0.198242] i2c-core: driver [dummy] registered [ 0.200683] omap_mux_init: Add partition: #1: core, flags: 0 [ 0.204437] OMAP3 Beagle Rev: C1/C2/C3 [ 0.235412] Reprogramming SDRC clock to 332000000 Hz [ 0.236755] Found NAND on CS0 [ 0.236785] Registering NAND on CS0 [ 0.238677] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.260498] omap-mcbsp.2: alias fck already exists [ 0.261749] omap-mcbsp.3: alias fck already exists [ 0.267395] OMAP DMA hardware revision 4.0 [ 0.273742] arm-pmu: alias fck already exists [ 0.372436] bio: create slab <bio-0> at 0 [ 0.507171] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.508972] i2c-core: driver [tps65023] registered [ 0.512786] i2c-core: driver [twl] registered [ 0.515808] SCSI subsystem initialized [ 0.520202] usbcore: registered new interface driver usbfs [ 0.521118] usbcore: registered new interface driver hub [ 0.522094] usbcore: registered new device driver usb [ 0.537139] i2c i2c-1: adapter [OMAP I2C adapter] registered [ 0.537994] i2c 1-0048: uevent [ 0.539367] twl 1-0048: probe [ 0.541015] i2c 1-0049: uevent [ 0.542419] dummy 1-0049: probe [ 0.542510] i2c i2c-1: client [dummy] registered with bus id 1-0049 [ 0.542907] i2c 1-004a: uevent [ 0.543670] dummy 1-004a: probe [ 0.543731] i2c i2c-1: client [dummy] registered with bus id 1-004a [ 0.544158] i2c 1-004b: uevent [ 0.544830] dummy 1-004b: probe [ 0.544921] i2c i2c-1: client [dummy] registered with bus id 1-004b [ 0.545227] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.545623] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.546142] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.546203] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.546478] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.546539] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.546630] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.546752] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.546844] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.546905] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.546997] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.547119] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.547210] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.547271] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.547363] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.547454] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.547576] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [ 0.547607] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [ 0.547698] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.547760] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.547851] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [ 0.547882] i2c i2c-1: master_xfer[1] R, addr=0x49, len=4 [ 0.547943] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [ 0.548034] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.548095] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.548187] omap_i2c omap_i2c.1: addr: 0x0049, len: 4, flags: 0x1, stop: 1 [ 0.548278] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.548309] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.548400] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [ 0.548461] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [ 0.548553] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.548614] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.549774] i2c i2c-1: master_xfer[0] W, addr=0x49, len=4 [ 0.549804] omap_i2c omap_i2c.1: addr: 0x0049, len: 4, flags: 0x0, stop: 1 [ 0.549926] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.549987] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.550170] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [ 0.550201] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [ 0.550323] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.550384] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.550476] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.550537] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.550628] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.550689] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.550781] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.550811] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.550903] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.550964] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.551086] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=3 [ 0.551116] omap_i2c omap_i2c.1: addr: 0x004a, len: 3, flags: 0x0, stop: 1 [ 0.551208] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.551300] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.551391] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.551422] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.551513] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.551574] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.551696] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.551727] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.551818] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.551879] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.552001] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.552032] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.552124] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.552246] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.552337] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.552398] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.552459] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.552581] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.552673] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [ 0.552703] i2c i2c-1: master_xfer[1] R, addr=0x49, len=3 [ 0.552764] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [ 0.552856] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.552917] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.553009] omap_i2c omap_i2c.1: addr: 0x0049, len: 3, flags: 0x1, stop: 1 [ 0.553100] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.553131] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.553222] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [ 0.553253] i2c i2c-1: master_xfer[1] R, addr=0x49, len=3 [ 0.553314] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [ 0.553405] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.553466] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.553527] omap_i2c omap_i2c.1: addr: 0x0049, len: 3, flags: 0x1, stop: 1 [ 0.553649] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.553680] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.553771] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=1 [ 0.553802] i2c i2c-1: master_xfer[1] R, addr=0x4a, len=1 [ 0.553833] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x0, stop: 0 [ 0.553924] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.553985] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.554077] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x1, stop: 1 [ 0.554168] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.554199] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.554290] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=1 [ 0.554321] i2c i2c-1: master_xfer[1] R, addr=0x4a, len=1 [ 0.554382] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x0, stop: 0 [ 0.554473] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.554534] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.554595] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x1, stop: 1 [ 0.554687] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.554718] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.554840] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=1 [ 0.554840] i2c i2c-1: master_xfer[1] R, addr=0x4a, len=2 [ 0.554901] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x0, stop: 0 [ 0.554992] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.555053] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.555145] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x1, stop: 1 [ 0.555236] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.555267] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.555358] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=1 [ 0.555389] i2c i2c-1: master_xfer[1] R, addr=0x4a, len=2 [ 0.555419] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x0, stop: 0 [ 0.555511] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.555572] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.555664] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x1, stop: 1 [ 0.555786] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.555786] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.555908] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=1 [ 0.555938] i2c i2c-1: master_xfer[1] R, addr=0x4a, len=1 [ 0.555969] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x0, stop: 0 [ 0.556060] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.556121] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.556213] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x1, stop: 1 [ 0.556732] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.556762] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.556945] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.556976] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.557098] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.557159] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.557250] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=1 [ 0.557281] i2c i2c-1: master_xfer[1] R, addr=0x4a, len=1 [ 0.557312] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x0, stop: 0 [ 0.557403] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.557464] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.557556] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x1, stop: 1 [ 0.557647] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.557678] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.557769] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.557830] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.557922] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.557983] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.558074] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 0.558105] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 0.558166] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 0.558258] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.558288] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.558380] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 0.558471] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.558502] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.558593] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 0.558624] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 0.558685] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 0.558776] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.558837] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.558898] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 0.558990] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.559020] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.559295] twl 1-0048: PIH (irq 23) chaining IRQs 338..346 [ 0.560180] twl 1-0048: power (irq 343) chaining IRQs 346..353 [ 0.560699] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [ 0.560729] i2c i2c-1: master_xfer[1] R, addr=0x49, len=1 [ 0.560760] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [ 0.560882] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.560943] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.561035] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x1, stop: 1 [ 0.561126] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.561157] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.561279] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [ 0.561309] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [ 0.561401] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.561462] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.565185] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371 [ 0.565246] i2c i2c-1: master_xfer[0] W, addr=0x49, len=6 [ 0.565338] omap_i2c omap_i2c.1: addr: 0x0049, len: 6, flags: 0x0, stop: 1 [ 0.565490] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.565521] omap_i2c omap_i2c.1: IRQ (ISR = 0x4000) [ 0.565612] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.565795] i2c i2c-1: master_xfer[0] W, addr=0x49, len=4 [ 0.565856] omap_i2c omap_i2c.1: addr: 0x0049, len: 4, flags: 0x0, stop: 1 [ 0.565948] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.566040] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.566162] gpiochip_find_base: found new base at 492 [ 0.567779] gpiochip_add: registered GPIOs 492 to 511 on device: twl4030 [ 0.569366] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [ 0.569488] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [ 0.569641] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.569702] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.569854] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [ 0.569885] i2c i2c-1: master_xfer[1] R, addr=0x49, len=1 [ 0.569946] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [ 0.570037] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.570098] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.570190] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x1, stop: 1 [ 0.570281] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.570312] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.570404] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [ 0.570465] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [ 0.570556] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.570648] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.570770] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.570800] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.570892] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.570983] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.571075] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.571289] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.571380] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.571472] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.571655] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=1 [ 0.571685] i2c i2c-1: master_xfer[1] R, addr=0x4a, len=1 [ 0.571716] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x0, stop: 0 [ 0.571838] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.571899] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.571960] omap_i2c omap_i2c.1: addr: 0x004a, len: 1, flags: 0x1, stop: 1 [ 0.572052] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.572082] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.572204] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.572235] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.572326] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.572418] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.572540] i2c i2c-1: master_xfer[0] W, addr=0x4a, len=2 [ 0.572601] omap_i2c omap_i2c.1: addr: 0x004a, len: 2, flags: 0x0, stop: 1 [ 0.572692] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.572784] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.580383] vdd_mpu_iva: 600 <--> 1450 mV normal [ 0.581024] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.581085] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.581207] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.581298] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.583740] vdd_core: 600 <--> 1450 mV normal [ 0.584197] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.584259] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.584411] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.584503] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.587371] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 0.587402] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 0.587493] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 0.587646] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.587738] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.587829] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 0.587951] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.587951] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.588073] VMMC1: 1850 <--> 3150 mV at 3000 mV normal standby [ 0.588104] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 0.588134] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 0.588195] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 0.588287] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.588348] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.588439] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 0.588531] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.588562] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.589202] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.589233] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.589355] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.589477] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.591949] VDAC: 1800 mV normal standby [ 0.592010] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 0.592041] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 0.592071] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 0.592193] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.592285] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.592376] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 0.592468] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.592498] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.593139] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.593200] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.593292] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.593688] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.596221] VDVI: 1800 mV normal standby [ 0.596252] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 0.596282] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 0.596343] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 0.596466] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.596527] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.596649] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 0.596740] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.596771] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.597320] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.597351] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.597473] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.597564] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.599975] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 0.600006] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 0.600067] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 0.600189] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.600250] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.600341] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 0.600433] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.600463] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.600585] VSIM: 1800 <--> 3000 mV at 1800 mV normal standby [ 0.600616] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 0.600646] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 0.600708] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 0.600799] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.601165] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.601348] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 0.601440] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 0.601470] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.602142] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 0.602203] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 0.602294] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 0.602416] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 0.602691] i2c i2c-1: client [twl4030] registered with bus id 1-0048 [ 0.602813] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 2600 kHz [ 0.617614] i2c i2c-3: adapter [OMAP I2C adapter] registered [ 0.618041] i2c 3-0050: uevent [ 0.618743] i2c i2c-3: client [eeprom] registered with bus id 3-0050 [ 0.618804] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 100 kHz [ 0.629852] Switching to clocksource 32k_counter [ 0.819976] NET: Registered protocol family 2 [ 0.822814] TCP established hash table entries: 8192 (order: 4, 65536 bytes) [ 0.823394] TCP bind hash table entries: 8192 (order: 6, 294912 bytes) [ 0.829284] TCP: Hash tables configured (established 8192 bind 8192) [ 0.829681] TCP: reno registered [ 0.829711] UDP hash table entries: 256 (order: 2, 20480 bytes) [ 0.830108] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) [ 0.831573] NET: Registered protocol family 1 [ 0.834106] RPC: Registered named UNIX socket transport module. [ 0.834167] RPC: Registered udp transport module. [ 0.834167] RPC: Registered tcp transport module. [ 0.834197] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.835723] NetWinder Floating Point Emulator V0.97 (double precision) [ 0.836212] CPU PMU: probing PMU on CPU 0 [ 0.836425] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available [ 1.058898] VFS: Disk quotas dquot_6.5.2 [ 1.059265] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.063476] NFS: Registering the id_resolver key type [ 1.064178] Key type id_resolver registered [ 1.064208] Key type id_legacy registered [ 1.064453] jffs2: version 2.2. (NAND) (SUMMARY) ? 2001-2006 Red Hat, Inc. [ 1.065338] msgmni has been set to 479 [ 1.070770] io scheduler noop registered [ 1.070800] io scheduler deadline registered [ 1.070922] io scheduler cfq registered (default) [ 1.075500] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.085754] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0 [ 1.088653] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1 [ 1.090850] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2 [ 2.409454] console [ttyO2] enabled [ 2.461151] brd: module loaded [ 2.493194] loop: module loaded [ 2.495727] i2c-core: driver [menelaus] registered [ 2.499206] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 2.502166] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 2.505554] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 2.509490] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 2.512207] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 2.515106] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 2.518920] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 2.521575] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 2.524749] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [ 2.527709] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [ 2.532348] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 2.535064] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 2.546630] mtdoops: mtd device (mtddev=name/number) must be supplied [ 2.550842] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit), page size: 2048, OOB size: 64 [ 2.557312] Creating 5 MTD partitions on "omap2-nand.0": [ 2.560302] 0x000000000000-0x000000080000 : "X-Loader" [ 2.573455] 0x000000080000-0x000000260000 : "U-Boot" [ 2.584594] 0x000000260000-0x000000280000 : "U-Boot Env" [ 2.593811] 0x000000280000-0x000000680000 : "Kernel" [ 2.606109] 0x000000680000-0x000010000000 : "File System" [ 2.828338] OneNAND driver initializing [ 2.847808] usbcore: registered new interface driver asix [ 2.851654] usbcore: registered new interface driver cdc_ether [ 2.855651] usbcore: registered new interface driver smsc95xx [ 2.859619] usbcore: registered new interface driver net1080 [ 2.863464] usbcore: registered new interface driver cdc_subset [ 2.867492] usbcore: registered new interface driver zaurus [ 2.871337] usbcore: registered new interface driver cdc_ncm [ 2.877563] usbcore: registered new interface driver cdc_wdm [ 2.880798] Initializing USB Mass Storage driver... [ 2.884307] usbcore: registered new interface driver usb-storage [ 2.887573] USB Mass Storage support registered. [ 2.891021] usbcore: registered new interface driver usbtest [ 2.896881] mousedev: PS/2 mouse device common for all mice [ 2.904998] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 2.908050] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 2.912017] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 2.914733] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 2.917541] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 2.920562] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=2 [ 2.923522] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 2.927398] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 2.930114] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 2.932830] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x1, stop: 1 [ 2.936737] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 2.939392] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 2.942138] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=3 [ 2.945190] omap_i2c omap_i2c.1: addr: 0x004b, len: 3, flags: 0x0, stop: 1 [ 2.949005] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 2.951751] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 2.956054] input: twl4030_pwrbutton as /devices/platform/omap_i2c.1/i2c-1/1-0049/twl4030_pwrbutton/input/input0 [ 2.965484] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 2.968749] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 2.971740] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 2.975677] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 2.978393] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 2.981201] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 2.986236] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 2.988891] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 2.991973] twl_rtc twl_rtc: Power up reset detected. [ 2.994750] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 2.997955] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.001770] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.004547] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.007415] twl_rtc twl_rtc: Enabling TWL-RTC [ 3.009796] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.012756] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.016693] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.019439] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.022308] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.025268] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.029571] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.032318] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.035125] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.038208] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.041168] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.045043] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.047760] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.050537] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.054443] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.057098] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.060821] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.063781] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.066772] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.070739] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.073425] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.076293] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.080108] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.082794] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.085632] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.088592] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.092468] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.095214] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.098388] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.101440] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=6 [ 3.104400] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.108276] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.110992] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.113708] omap_i2c omap_i2c.1: addr: 0x004b, len: 6, flags: 0x1, stop: 1 [ 3.117736] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.120422] omap_i2c omap_i2c.1: IRQ (ISR = 0x2000) [ 3.123199] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.125946] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.128906] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=6 [ 3.131927] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.135742] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.138519] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.141235] omap_i2c omap_i2c.1: addr: 0x004b, len: 6, flags: 0x1, stop: 1 [ 3.145172] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.147827] omap_i2c omap_i2c.1: IRQ (ISR = 0x2000) [ 3.150604] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.153350] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.156372] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.159362] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.163208] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.165924] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.168640] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.172546] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.175201] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.178009] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.180969] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.184814] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.187561] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.190307] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.193328] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=6 [ 3.196319] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.200103] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.202880] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.205596] omap_i2c omap_i2c.1: addr: 0x004b, len: 6, flags: 0x1, stop: 1 [ 3.209594] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.212249] omap_i2c omap_i2c.1: IRQ (ISR = 0x2000) [ 3.214965] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.219451] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 [ 3.223144] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.226287] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.230133] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.232910] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.235717] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.238677] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=2 [ 3.241760] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.245574] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.248352] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.251129] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x1, stop: 1 [ 3.254943] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.257629] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.260498] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=3 [ 3.263580] omap_i2c omap_i2c.1: addr: 0x004b, len: 3, flags: 0x0, stop: 1 [ 3.267425] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.270141] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.273895] i2c /dev entries driver [ 3.278717] i2c-dev: adapter [OMAP I2C adapter] registered as minor 1 [ 3.283691] i2c-dev: adapter [OMAP I2C adapter] registered as minor 3 [ 3.287353] Driver for 1-wire Dallas network protocol. [ 3.295043] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec [ 3.300048] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.303222] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.307067] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.309814] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.312713] twl4030_wdt twl4030_wdt: Failed to register misc device [ 3.316192] twl4030_wdt: probe of twl4030_wdt failed with error -16 [ 3.323455] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [ 3.326690] i2c i2c-1: master_xfer[1] R, addr=0x49, len=1 [ 3.329711] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [ 3.333679] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.336364] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.339202] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x1, stop: 1 [ 3.343139] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.345794] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.348602] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [ 3.351867] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [ 3.355682] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.358459] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.362335] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk [ 3.365844] omap-dma-engine omap-dma-engine: allocating channel for 62 [ 3.369506] omap-dma-engine omap-dma-engine: allocating channel for 61 [ 3.374359] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.377319] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.380371] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.384368] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.387054] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.389953] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.393768] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.396423] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.399353] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.402313] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.405426] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.409240] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.412017] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.414794] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.418609] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.421264] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.424163] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.427124] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.430175] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.433990] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.436767] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.439514] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.443420] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.446075] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.448822] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.451873] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.455688] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.458404] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.461212] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.464172] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.467193] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.471008] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.473693] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.476501] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.480285] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.482971] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.485778] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.488708] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.491760] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.495574] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.498321] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.501068] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.504852] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.507537] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.510345] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.513366] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.516326] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.520141] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.522888] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.525634] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.529510] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.532165] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.534912] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.537933] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.540893] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.544769] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.547454] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.550170] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.554046] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.556732] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.559478] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.562499] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.566314] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.569061] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.677520] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.680450] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.683410] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.687316] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.690002] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.692749] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.696624] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.699279] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.702117] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.705078] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.708953] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.711700] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.714447] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.717468] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.720428] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.724304] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.727020] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.729736] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.733612] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.736267] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.739013] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.742034] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.745849] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.748626] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.857482] i2c i2c-1: master_xfer[0] W, addr=0x49, len=4 [ 3.860443] omap_i2c omap_i2c.1: addr: 0x0049, len: 4, flags: 0x0, stop: 1 [ 3.864288] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.867065] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.869812] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [ 3.872833] i2c i2c-1: master_xfer[1] R, addr=0x49, len=5 [ 3.875793] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [ 3.879608] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.882385] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.885101] omap_i2c omap_i2c.1: addr: 0x0049, len: 5, flags: 0x1, stop: 1 [ 3.889007] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.891662] omap_i2c omap_i2c.1: IRQ (ISR = 0x2000) [ 3.894378] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.897186] i2c i2c-1: master_xfer[0] W, addr=0x49, len=6 [ 3.900146] omap_i2c omap_i2c.1: addr: 0x0049, len: 6, flags: 0x0, stop: 1 [ 3.904022] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.906677] omap_i2c omap_i2c.1: IRQ (ISR = 0x4000) [ 3.909393] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.914062] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.916992] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.920135] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.923980] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.926666] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.929534] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.933349] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.936035] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.938934] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.941894] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.944946] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.948760] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.951538] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.954284] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.958099] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.960754] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.963653] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 3.966705] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 3.970520] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.973236] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.976623] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 3.979583] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 3.982666] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 3.986480] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 3.989196] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 3.992034] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 3.995849] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 3.998504] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.001403] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 4.004333] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 4.007415] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 4.011230] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.014007] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.016784] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 4.020599] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.023254] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.026123] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 4.029174] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 4.032165] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 4.035949] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.038726] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.041473] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 4.045379] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.048034] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.050781] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 4.053802] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 4.057617] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.060394] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.063232] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 4.066192] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 4.069213] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 4.073028] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.075805] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.078521] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 4.082336] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.084991] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.087799] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 4.090759] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 4.093780] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 4.097595] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.100341] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.103057] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 4.106933] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.109588] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.112396] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 4.115447] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 4.119232] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.121978] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.279876] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [ 4.282836] i2c i2c-1: master_xfer[1] R, addr=0x49, len=1 [ 4.285858] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [ 4.289855] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.292541] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.297668] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x1, stop: 1 [ 4.301544] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.304199] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.308349] usbcore: registered new interface driver usbhid [ 4.311523] usbhid: USB HID core driver [ 4.317321] oprofile: using arm/armv7 [ 4.320526] TCP: cubic registered [ 4.322326] Initializing XFRM netlink socket [ 4.324859] NET: Registered protocol family 17 [ 4.327514] NET: Registered protocol family 15 [ 4.330535] Key type dns_resolver registered [ 4.333038] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 [ 4.348693] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 4.351776] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 4.354827] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 4.358795] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.361511] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.365783] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 4.369659] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.372314] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.377227] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 4.380279] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 4.384185] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.386932] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.391601] PM: no software I/O chain control; some wakeups may be lost [ 4.395812] ThumbEE CPU extension supported. [ 4.443084] clock: disabling unused clocks to save power [ 4.452331] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 4.455291] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 4.458374] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 4.462371] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.465087] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.467987] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 4.471801] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.474487] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.477386] VDVI: incomplete constraints, leaving on [ 4.480102] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 4.483306] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 4.486267] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 4.490173] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.492858] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.495666] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 4.499572] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.502227] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.505035] VDAC: incomplete constraints, leaving on [ 4.512847] input: gpio-keys as /devices/platform/gpio-keys/input/input1 [ 4.519531] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 4.522644] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 4.525665] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 4.529632] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.532348] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.535156] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 4.539123] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.541778] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.544830] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 4.547821] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 4.551635] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.554443] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.557281] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 4.560363] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=6 [ 4.563323] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 4.567138] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 4.569915] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.572692] omap_i2c omap_i2c.1: addr: 0x004b, len: 6, flags: 0x1, stop: 1 [ 4.576843] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 4.579498] omap_i2c omap_i2c.1: IRQ (ISR = 0x2000) [ 4.582244] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 4.585235] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:01 UTC (946684801) [ 4.595428] Waiting for root device /dev/mmcblk0p2... [ 4.702789] mmc0: SD Status: Invalid Allocation Unit size. [ 4.708129] mmc0: new SD card at address 8001 [ 4.714416] mmcblk0: mmc0:8001 SD02G 1.89 GiB [ 4.724670] mmcblk0: p1 p2 [ 6.088897] kjournald starting. Commit interval 5 seconds [ 6.092681] EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended [ 6.279846] EXT3-fs (mmcblk0p2): using internal journal [ 6.287200] EXT3-fs (mmcblk0p2): recovery complete [ 6.289825] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode [ 6.294158] VFS: Mounted root (ext3 filesystem) on device 179:2. [ 6.298675] Freeing init memory: 320K INIT: version 2.86 booting Starting the hotplug events dispatcher udevd Synthesizing the initial hotplug events [ 9.449676] twl 1-0048: uevent [ 9.467559] dummy 1-0049: uevent [ 9.472778] dummy 1-004a: uevent [ 9.519195] dummy 1-004b: uevent [ 9.536560] i2c 3-0050: uevent Remounting root file system... mount: according to mtab, /proc is already mounted on /proc WARNING: Couldn't open directory /lib/modules/3.7.0-rc3: No such file or directory FATAL: Could not open /lib/modules/3.7.0-rc3/modules.dep.temp for writing: No such file or directory root: mount: mount point /proc/bus/usb does not exist Setting up IP spoofing protection: rp_filter. Configuring network interfaces... modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory ifconfig: SIOCGIFFLAGS: No such device modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory eth0 No such device modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory udhcpc: SIOCGIFINDEX: No such device done. Starting portmap daemon: portmap. [ 24.558410] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 24.561553] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 24.564758] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 24.568695] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.571411] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.574218] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 24.578186] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 24.580871] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.583801] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 24.586761] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 24.590576] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.593383] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.596191] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 24.599243] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=6 [ 24.602203] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 24.606018] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.608764] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.611541] omap_i2c omap_i2c.1: addr: 0x004b, len: 6, flags: 0x1, stop: 1 [ 24.615631] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 24.618286] omap_i2c omap_i2c.1: IRQ (ISR = 0x2000) [ 24.621002] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) Tue Jul 22 00:18:00 UTC 2008 [ 24.757415] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 24.760406] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 24.763549] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 24.767395] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.770111] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.773162] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 24.777038] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 24.779693] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.782623] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 24.785614] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 24.789520] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.792297] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.795166] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=7 [ 24.798126] omap_i2c omap_i2c.1: addr: 0x004b, len: 7, flags: 0x0, stop: 1 [ 24.801940] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.804626] omap_i2c omap_i2c.1: IRQ (ISR = 0x4000) [ 24.807434] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.810272] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 24.813232] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 24.817047] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.819824] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.823242] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 24.826324] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=1 [ 24.829345] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 24.833282] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.836059] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.838958] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x1, stop: 1 [ 24.842864] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 24.845550] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.848297] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=2 [ 24.851348] omap_i2c omap_i2c.1: addr: 0x004b, len: 2, flags: 0x0, stop: 1 [ 24.855163] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.857940] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.860687] i2c i2c-1: master_xfer[0] W, addr=0x4b, len=1 [ 24.863647] i2c i2c-1: master_xfer[1] R, addr=0x4b, len=6 [ 24.866668] omap_i2c omap_i2c.1: addr: 0x004b, len: 1, flags: 0x0, stop: 0 [ 24.870483] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [ 24.873260] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [ 24.875976] omap_i2c omap_i2c.1: addr: 0x004b, len: 6, flags: 0x1, stop: 1 [ 24.880065] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [ 24.882720] omap_i2c omap_i2c.1: IRQ (ISR = 0x2000) [ 24.885528] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) INIT: Entering runlevel: 5 ALSA: Restoring mixer settings... /usr/sbin/alsactl: load_state:1327: No soundcards found... Starting Dropbear SSH server: modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory dropbear. Starting advanced power management daemon: No APM support in kernel (failed.) Starting system message bus: dbus. Starting syslogd/klogd: start-stop-daemon: lseek: Invalid argument * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon [ ok ] Starting Bluetooth subsystem: hcidmodprobe: FATAL: Could not load /lib/modules/3.7.0-rc3/modules.dep: No such file or directory hid2hci. .-------. | | .-. | | |-----.-----.-----.| | .----..-----.-----. | | | __ | ---'| '--.| .-'| | | | | | | | |--- || --'| | | ' | | | | '---'---'--'--'--. |-----''----''--' '-----'-'-'-' -' | '---' The Angstrom Distribution beagleboard ttyO2 Angstrom 2008.1-test-20080712 beagleboard ttyO2 beagleboard login: ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 12:17 ` Paul Walmsley @ 2012-10-30 12:32 ` Felipe Balbi 2012-10-30 12:50 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Felipe Balbi @ 2012-10-30 12:32 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tue, Oct 30, 2012 at 12:17:11PM +0000, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/7cf1545c/attachment.sig> ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 12:32 ` Felipe Balbi @ 2012-10-30 12:50 ` Paul Walmsley 2012-10-30 12:54 ` Felipe Balbi 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-30 12:50 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 12:50 ` Paul Walmsley @ 2012-10-30 12:54 ` Felipe Balbi 2012-10-30 13:17 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Felipe Balbi @ 2012-10-30 12:54 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tue, Oct 30, 2012 at 12:50:52PM +0000, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/14ae2ba0/attachment.sig> ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 12:54 ` Felipe Balbi @ 2012-10-30 13:17 ` Paul Walmsley 2012-10-30 14:04 ` Paul Walmsley 2012-10-31 8:22 ` Jean Pihet 0 siblings, 2 replies; 69+ messages in thread From: Paul Walmsley @ 2012-10-30 13:17 UTC (permalink / raw) To: linux-arm-kernel On Tue, 30 Oct 2012, Felipe Balbi wrote: > On Tue, Oct 30, 2012 at 12:50:52PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 13:17 ` Paul Walmsley @ 2012-10-30 14:04 ` Paul Walmsley 2012-10-31 8:34 ` Jean Pihet 2012-10-31 8:22 ` Jean Pihet 1 sibling, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-30 14:04 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 14:04 ` Paul Walmsley @ 2012-10-31 8:34 ` Jean Pihet 2012-10-31 9:05 ` Rafael J. Wysocki 0 siblings, 1 reply; 69+ messages in thread From: Jean Pihet @ 2012-10-31 8:34 UTC (permalink / raw) To: linux-arm-kernel Paul, - Added Rafael for the PM QoS discussion - On Tue, Oct 30, 2012 at 10:04 AM, Paul Walmsley <paul@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-31 8:34 ` Jean Pihet @ 2012-10-31 9:05 ` Rafael J. Wysocki 0 siblings, 0 replies; 69+ messages in thread From: Rafael J. Wysocki @ 2012-10-31 9:05 UTC (permalink / raw) To: linux-arm-kernel 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 <paul@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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 13:17 ` Paul Walmsley 2012-10-30 14:04 ` Paul Walmsley @ 2012-10-31 8:22 ` Jean Pihet 2012-10-31 10:49 ` Kevin Hilman 1 sibling, 1 reply; 69+ messages in thread From: Jean Pihet @ 2012-10-31 8:22 UTC (permalink / raw) To: linux-arm-kernel On Tue, Oct 30, 2012 at 9:17 AM, Paul Walmsley <paul@pwsan.com> wrote: > On Tue, 30 Oct 2012, Felipe Balbi wrote: > >> On Tue, Oct 30, 2012 at 12:50:52PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-31 8:22 ` Jean Pihet @ 2012-10-31 10:49 ` Kevin Hilman 2012-10-31 21:11 ` Jean Pihet 0 siblings, 1 reply; 69+ messages in thread From: Kevin Hilman @ 2012-10-31 10:49 UTC (permalink / raw) To: linux-arm-kernel Hi Jean, Jean Pihet <jean.pihet@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-31 10:49 ` Kevin Hilman @ 2012-10-31 21:11 ` Jean Pihet 2012-11-01 2:44 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Jean Pihet @ 2012-10-31 21:11 UTC (permalink / raw) To: linux-arm-kernel Hi Kevin, On Wed, Oct 31, 2012 at 6:49 AM, Kevin Hilman <khilman@deeprootsystems.com> wrote: > Hi Jean, > > Jean Pihet <jean.pihet@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-31 21:11 ` Jean Pihet @ 2012-11-01 2:44 ` Paul Walmsley 2012-11-01 7:51 ` Jean Pihet 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-11-01 2:44 UTC (permalink / raw) To: linux-arm-kernel 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-kernel&m=135167153510814&w=2 - Paul ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-11-01 2:44 ` Paul Walmsley @ 2012-11-01 7:51 ` Jean Pihet 2012-11-03 21:39 ` Jean Pihet 0 siblings, 1 reply; 69+ messages in thread From: Jean Pihet @ 2012-11-01 7:51 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On Wed, Oct 31, 2012 at 10:44 PM, Paul Walmsley <paul@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-kernel&m=135167153510814&w=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-omap&m=135161909714517&w=2 Regards, Jean > > > - Paul ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-11-01 7:51 ` Jean Pihet @ 2012-11-03 21:39 ` Jean Pihet 2012-11-05 3:15 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Jean Pihet @ 2012-11-03 21:39 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On Thu, Nov 1, 2012 at 8:51 AM, Jean Pihet <jean.pihet@newoldbits.com> wrote: > Hi Paul, > > On Wed, Oct 31, 2012 at 10:44 PM, Paul Walmsley <paul@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-kernel&m=135167153510814&w=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 #0f6000020000000004013ef109008009 Hit any key to stop autoboot: 0 reading uimage 4148008 bytes read ## Booting kernel from Legacy Image at 80300000 ... 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.000000] Booting Linux on physical CPU 0 [ 0.000000] Linux version 3.7.0-rc1 (def at rachael) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #2 SMP Sat Nov 3 21:56:11 CET 2012 [ 0.000000] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] Machine: OMAP3 Beagle Board [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) [ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [ 0.000000] PERCPU: Embedded 9 pages/cpu @c0e40000 s12928 r8192 d15744 u36864 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [ 0.000000] Kernel command line: console=ttyO2,230400n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Memory: 127MB = 127MB total [ 0.000000] Memory: 115316k/115316k available, 15756k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc07037dc (7150 kB) [ 0.000000] .init : 0xc0704000 - 0xc0754280 ( 321 kB) [ 0.000000] .data : 0xc0756000 - 0xc07e15a0 ( 558 kB) [ 0.000000] .bss : 0xc07e15c4 - 0xc0d3bfac (5483 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts [ 0.000000] Total of 96 interrupts on 1 active controller [ 0.000000] OMAP clockevent source: GPTIMER12 at 32768 Hz [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 [ 0.000000] ... CHAINHASH_SIZE: 16384 [ 0.000000] memory used by lock dependency info: 3695 kB [ 0.000000] per task-struct memory footprint: 1152 bytes [ 0.001190] Calibrating delay loop... 324.52 BogoMIPS (lpj=1265664) [ 0.106964] pid_max: default: 32768 minimum: 301 [ 0.107757] Security Framework initialized [ 0.108001] Mount-cache hash table entries: 512 [ 0.114196] CPU: Testing write buffer coherency: ok [ 0.115478] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [ 0.115600] Setting up static identity map for 0x8051ebe0 - 0x8051ec50 [ 0.119537] Brought up 1 CPUs [ 0.119567] SMP: Total of 1 processors activated (324.52 BogoMIPS). [ 0.142547] pinctrl core: initialized pinctrl subsystem [ 0.151123] regulator-dummy: no parameters [ 0.154083] NET: Registered protocol family 16 [ 0.155853] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.158386] omap-gpmc omap-gpmc: GPMC revision 5.0 [ 0.175537] OMAP GPIO hardware version 2.5 [ 0.202301] omap_mux_init: Add partition: #1: core, flags: 0 [ 0.205810] OMAP3 Beagle Rev: Ax/Bx [ 0.236938] Reprogramming SDRC clock to 332000000 Hz [ 0.238708] Found NAND on CS0 [ 0.238739] Registering NAND on CS0 [ 0.240417] find_device_opp: Invalid parameters [ 0.240661] find_device_opp: Invalid parameters [ 0.240722] find_device_opp: Invalid parameters [ 0.240783] find_device_opp: Invalid parameters [ 0.240844] find_device_opp: Invalid parameters [ 0.241149] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.262451] omap-mcbsp.2: alias fck already exists [ 0.263702] omap-mcbsp.3: alias fck already exists [ 0.269287] OMAP DMA hardware revision 4.0 [ 0.275695] arm-pmu: alias fck already exists [ 0.372833] bio: create slab <bio-0> at 0 [ 0.504943] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.513244] SCSI subsystem initialized [ 0.517700] usbcore: registered new interface driver usbfs [ 0.518524] usbcore: registered new interface driver hub [ 0.519470] usbcore: registered new device driver usb [ 0.542327] twl 1-0048: PIH (irq 23) chaining IRQs 338..346 [ 0.543212] twl 1-0048: power (irq 343) chaining IRQs 346..353 [ 0.547882] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371 [ 0.560913] vdd_mpu_iva: 600 <--> 1450 mV normal [ 0.564697] vdd_core: 600 <--> 1450 mV normal [ 0.568145] VMMC1: 1850 <--> 3150 mV at 3000 mV normal standby [ 0.572204] VDAC: 1800 mV normal standby [ 0.575622] VDVI: 1800 mV normal standby [ 0.579803] VSIM: 1800 <--> 3000 mV at 1800 mV normal standby [ 0.581176] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 2600 kHz [ 0.584350] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 100 kHz [ 0.595794] Switching to clocksource 32k_counter [ 0.784149] NET: Registered protocol family 2 [ 0.787017] TCP established hash table entries: 4096 (order: 3, 32768 bytes) [ 0.787414] TCP bind hash table entries: 4096 (order: 5, 147456 bytes) [ 0.790130] TCP: Hash tables configured (established 4096 bind 4096) [ 0.790435] TCP: reno registered [ 0.790496] UDP hash table entries: 256 (order: 2, 20480 bytes) [ 0.790863] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) [ 0.792205] NET: Registered protocol family 1 [ 0.794158] RPC: Registered named UNIX socket transport module. [ 0.794189] RPC: Registered udp transport module. [ 0.794219] RPC: Registered tcp transport module. [ 0.794219] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.795715] NetWinder Floating Point Emulator V0.97 (double precision) [ 0.796173] CPU PMU: probing PMU on CPU 0 [ 0.796386] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available [ 1.017608] VFS: Disk quotas dquot_6.5.2 [ 1.018005] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.022155] NFS: Registering the id_resolver key type [ 1.022857] Key type id_resolver registered [ 1.022888] Key type id_legacy registered [ 1.023101] jffs2: version 2.2. (NAND) (SUMMARY) ? 2001-2006 Red Hat, Inc. [ 1.023986] msgmni has been set to 225 [ 1.029388] io scheduler noop registered [ 1.029449] io scheduler deadline registered [ 1.029571] io scheduler cfq registered (default) [ 1.034118] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.044128] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0 [ 1.047027] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1 [ 1.049133] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2 [ 1.408569] console [ttyO2] enabled [ 1.459045] brd: module loaded [ 1.491302] loop: module loaded [ 1.504882] mtdoops: mtd device (mtddev=name/number) must be supplied [ 1.509094] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit), page size: 2048, OOB size: 64 [ 1.515777] Creating 5 MTD partitions on "omap2-nand.0": [ 1.518737] 0x000000000000-0x000000080000 : "X-Loader" [ 1.531433] 0x000000080000-0x000000260000 : "U-Boot" [ 1.542541] 0x000000260000-0x000000280000 : "U-Boot Env" [ 1.551788] 0x000000280000-0x000000680000 : "Kernel" [ 1.564239] 0x000000680000-0x000010000000 : "File System" [ 1.793273] OneNAND driver initializing [ 1.812469] usbcore: registered new interface driver asix [ 1.816345] usbcore: registered new interface driver cdc_ether [ 1.820343] usbcore: registered new interface driver smsc95xx [ 1.824310] usbcore: registered new interface driver net1080 [ 1.828124] usbcore: registered new interface driver cdc_subset [ 1.832153] usbcore: registered new interface driver zaurus [ 1.835937] usbcore: registered new interface driver cdc_ncm [ 1.842102] usbcore: registered new interface driver cdc_wdm [ 1.845184] Initializing USB Mass Storage driver... [ 1.848754] usbcore: registered new interface driver usb-storage [ 1.852020] USB Mass Storage support registered. [ 1.855407] usbcore: registered new interface driver usbtest [ 1.860931] mousedev: PS/2 mouse device common for all mice [ 1.872131] input: twl4030_pwrbutton as /devices/platform/omap_i2c.1/i2c-1/1-0049/twl4030_pwrbutton/input/input0 [ 1.882110] twl_rtc twl_rtc: Enabling TWL-RTC [ 1.890533] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 [ 1.897399] i2c /dev entries driver [ 1.903747] Driver for 1-wire Dallas network protocol. [ 1.911224] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec [ 1.916412] twl4030_wdt twl4030_wdt: Failed to register misc device [ 1.920318] twl4030_wdt: probe of twl4030_wdt failed with error -16 [ 1.929351] omap_hsmmc omap_hsmmc.0: multiblock reads disabled due to 35xx erratum 2.1.1.128; MMC read performance may suffer [ 1.936065] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk [ 1.939361] omap-dma-engine omap-dma-engine: allocating channel for 62 [ 1.943084] omap-dma-engine omap-dma-engine: allocating channel for 61 [ 2.332794] usbcore: registered new interface driver usbhid [ 2.335906] usbhid: USB HID core driver [ 2.343688] oprofile: using arm/armv7 [ 2.346954] TCP: cubic registered [ 2.348754] Initializing XFRM netlink socket [ 2.351257] NET: Registered protocol family 17 [ 2.353790] NET: Registered protocol family 15 [ 2.356872] Key type dns_resolver registered [ 2.359313] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 [ 2.376007] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva [ 2.380218] omap2_set_init_voltage: unable to set vdd_mpu_iva [ 2.384307] PM: no software I/O chain control; some wakeups may be lost [ 2.388549] ThumbEE CPU extension supported. [ 2.435852] clock: disabling unused clocks to save power [ 2.445678] VDVI: incomplete constraints, leaving on [ 2.448852] VDAC: incomplete constraints, leaving on [ 2.456817] input: gpio-keys as /devices/platform/gpio-keys/input/input1 [ 2.465118] twl_rtc twl_rtc: setting system clock to 2010-07-22 02:43:19 UTC (1279766599) [ 2.475555] Waiting for root device /dev/mmcblk0p2... [ 2.499633] mmc0: new SD card at address e624 [ 2.506134] mmcblk0: mmc0:e624 SD01G 968 MiB [ 2.520111] mmcblk0: p1 p2 [ 4.051177] kjournald starting. Commit interval 5 seconds [ 4.059448] EXT3-fs (mmcblk0p2): using internal journal [ 4.067016] EXT3-fs (mmcblk0p2): recovery complete [ 4.069641] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode [ 4.074005] VFS: Mounted root (ext3 filesystem) on device 179:2. [ 4.078399] Freeing init memory: 320K INIT: version 2.86 booting Starting the hotplug events dispatcher udevd Synthesizing the initial hotplug events Remounting root file system... mount: according to mtab, /proc is already mounted on /proc WARNING: Couldn't open directory /lib/modules/3.7.0-rc1: No such file or directory FATAL: Could not open /lib/modules/3.7.0-rc1/modules.dep.temp for writing: No such file or directory root: mount: mount point /proc/bus/usb does not exist Setting up IP spoofing protection: rp_filter. Configuring network interfaces... modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory ifconfig: SIOCGIFFLAGS: No such device modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory eth0 No such device modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory udhcpc: SIOCGIFINDEX: No such device done. Starting portmap daemon: portmap. Fri Jul 22 02:12:00 UTC 2011 [ 33.424743] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 34.440338] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 34.443603] twl: i2c_read failed to transfer all messages [ 34.446533] twl_rtc: Could not read TWLregister D - error -110 [ 34.449768] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110 INIT: Entering runlevel: 5 ALSA: Restoring mixer settings... /usr/sbin/alsactl: load_state:1327: No soundcards found... Starting Dropbear SSH server: modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory dropbear. Starting advanced power management daemon: No APM support in kernel (failed.) Starting system message bus: dbus. Starting syslogd/klogd: start-stop-daemon: lseek: Invalid argument * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon [ ok ] Starting Bluetooth subsystem:modprobe: FATAL: Could not load /lib/modules/3.7.0-rc1/modules.dep: No such file or directory hcid hid2hci. .-------. | | .-. | | |-----.-----.-----.| | .----..-----.-----. | | | __ | ---'| '--.| .-'| | | | | | | | |--- || --'| | | ' | | | | '---'---'--'--'--. |-----''----''--' '-----'-'-'-' -' | '---' The Angstrom Distribution beagleboard ttyO2 Angstrom 2008.1-test-20080712 beagleboard ttyO2 beagleboard login: root login[2013]: root login on `ttyO2' root at beagleboard:~# hwclock -s root at beagleboard:~# cat /sys/devices/platform/omap_i2c.1/i2c-1/1-004b/twl_rtc/rtc/rtc0/date 2011-07-22 root at beagleboard:~# cat /sys/devices/platform/omap_i2c.1/i2c-1/1-004b/twl_rtc/rtc/rtc0/time 02:12:00 root at beagleboard:~# >> >> >> - Paul More investigation on-going, so more to come! Regards, Jean ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-11-03 21:39 ` Jean Pihet @ 2012-11-05 3:15 ` Paul Walmsley 2012-11-05 9:26 ` Jean Pihet 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-11-05 3:15 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-11-05 3:15 ` Paul Walmsley @ 2012-11-05 9:26 ` Jean Pihet 2012-11-06 0:01 ` Kevin Hilman 0 siblings, 1 reply; 69+ messages in thread From: Jean Pihet @ 2012-11-05 9:26 UTC (permalink / raw) To: linux-arm-kernel Paul, On Mon, Nov 5, 2012 at 4:15 AM, Paul Walmsley <paul@pwsan.com> wrote: > Hi Jean, > > On Sat, 3 Nov 2012, Jean Pihet wrote: > >> The setup is as identical as possible to yours: >> - U-Boot 2011.06-dirty (Sep 04 2012 - 17:06:58) from >> http://www.pwsan.com/tmp/3530es3beagle-MLO-u-boot-20121023.tar.bz2. >> Please note that the MLO image does not run on my board and so I had >> to use my known-to-work image. > > Interesting... > >> The result is that I could reproduce the issue but it happens much >> more rarely on my side (only once vs quasi 100% on ~50 boot cycles). > > Hmm... > >> The issue is triggered by running 'hwclock --systohc' while the >> system is heavily loaded (running depmod etc.). > > OK. > >> More investigation on-going, so more to come! > > Great, keep us posted. I ran some intensive stress tests on the I2C and ... unfortunately I could not trigger the problem. It looks like the issue is caused by some transient situation where the CORE and/or I2C is in a low power state. Here are the tests that have been performed from the user space: - stress test the I2C IRQ handler by reading and writing the RTC, and checking the amount of IRQs for the I2C bus. In that case the CORE never goes in low power mode, - stress test the CORE low power and wake-up transition by adjusting the autosuspend delay (e.g. /sys/devices/platform/omap_i2c.1/power/autosuspend_delay_ms) and accessing the RTC after the CORE has gone in low power. Those tests have been run for hours (>200000 IRQs) and the I2C timeout issue could not be observed. The target low power mode is RET (not tried with OFF). The next step is to detect an error situation and have data logged about the state at that moment. What do you think? This brings an interesting discussion. As you indicated earlier, withtout CPU_IDLE enabled nothing except the autosuspend delay is preventing the power domains to go in low power mode. This could lead to situations where latency constraints are not respected. The easy and straight forward solution is to enable CPU_IDLE and use the PM QoS constraints. What do you think? Regards, Jean > > Will try to kick off those tests you requested within the next 24-48 > hours. > > > - Paul ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-11-05 9:26 ` Jean Pihet @ 2012-11-06 0:01 ` Kevin Hilman 2012-11-06 9:27 ` Jean Pihet 2012-11-06 10:06 ` Shubhrajyoti Datta 0 siblings, 2 replies; 69+ messages in thread From: Kevin Hilman @ 2012-11-06 0:01 UTC (permalink / raw) To: linux-arm-kernel Jean Pihet <jean.pihet@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.000000 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.975555] twl: i2c_read failed to transfer all messages [ 40.975555] 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. real 0m 3.50s user 0m 0.00s sys 0m 0.10s Date: Fri Dec 31 17:00:40 MST 1999 hwclock: Sat Jan 1 00:00:40 2000 0.000000 seconds ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-11-06 0:01 ` Kevin Hilman @ 2012-11-06 9:27 ` Jean Pihet 2012-11-06 16:13 ` Paul Walmsley 2012-11-06 10:06 ` Shubhrajyoti Datta 1 sibling, 1 reply; 69+ messages in thread From: Jean Pihet @ 2012-11-06 9:27 UTC (permalink / raw) To: linux-arm-kernel Hi Kevin, Paul, On Tue, Nov 6, 2012 at 1:01 AM, Kevin Hilman <khilman@deeprootsystems.com> wrote: > Jean Pihet <jean.pihet@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-kernel&m=134744383120921&w=2 [2] http://marc.info/?l=linux-omap&m=134795835604288&w=2 [3] http://marc.info/?l=linux-omap&m=134815730108344&w=2 [4] http://marc.info/?l=linux-omap&m=134795836904299&w=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.000000 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.975555] twl: i2c_read failed to transfer all messages > [ 40.975555] 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. > real 0m 3.50s > user 0m 0.00s > sys 0m 0.10s > Date: Fri Dec 31 17:00:40 MST 1999 > hwclock: Sat Jan 1 00:00:40 2000 0.000000 seconds ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-11-06 9:27 ` Jean Pihet @ 2012-11-06 16:13 ` Paul Walmsley 0 siblings, 0 replies; 69+ messages in thread From: Paul Walmsley @ 2012-11-06 16:13 UTC (permalink / raw) To: linux-arm-kernel On Tue, 6 Nov 2012, Jean Pihet wrote: > On Tue, Nov 6, 2012 at 1:01 AM, Kevin Hilman > <khilman@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-11-06 0:01 ` Kevin Hilman 2012-11-06 9:27 ` Jean Pihet @ 2012-11-06 10:06 ` Shubhrajyoti Datta 1 sibling, 0 replies; 69+ messages in thread From: Shubhrajyoti Datta @ 2012-11-06 10:06 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 6, 2012 at 5:31 AM, Kevin Hilman <khilman@deeprootsystems.com> wrote: > Jean Pihet <jean.pihet@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 at vger.kernel.org/msg79841.html ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-23 19:23 ` Jean Pihet 2012-10-25 10:12 ` Felipe Balbi @ 2012-10-30 4:16 ` Paul Walmsley 2012-10-30 8:54 ` Jean Pihet 1 sibling, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-30 4:16 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 4:16 ` Paul Walmsley @ 2012-10-30 8:54 ` Jean Pihet 2012-10-30 11:23 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Jean Pihet @ 2012-10-30 8:54 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley <paul@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 8:54 ` Jean Pihet @ 2012-10-30 11:23 ` Paul Walmsley 2012-10-31 8:18 ` Jean Pihet 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-30 11:23 UTC (permalink / raw) To: linux-arm-kernel Hi Jean, On Tue, 30 Oct 2012, Jean Pihet wrote: > On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley <paul@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-30 11:23 ` Paul Walmsley @ 2012-10-31 8:18 ` Jean Pihet 0 siblings, 0 replies; 69+ messages in thread From: Jean Pihet @ 2012-10-31 8:18 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On Tue, Oct 30, 2012 at 7:23 AM, Paul Walmsley <paul@pwsan.com> wrote: > Hi Jean, > > On Tue, 30 Oct 2012, Jean Pihet wrote: > >> On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley <paul@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-22 16:12 ` Jean Pihet 2012-10-22 17:26 ` Jean Pihet @ 2012-10-23 19:17 ` Kevin Hilman 2012-10-23 19:18 ` Paul Walmsley 2 siblings, 0 replies; 69+ messages in thread From: Kevin Hilman @ 2012-10-23 19:17 UTC (permalink / raw) To: linux-arm-kernel Jean Pihet <jean.pihet@newoldbits.com> writes: > Hi, > > On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley <paul@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.pihet@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-22 16:12 ` Jean Pihet 2012-10-22 17:26 ` Jean Pihet 2012-10-23 19:17 ` Kevin Hilman @ 2012-10-23 19:18 ` Paul Walmsley 2 siblings, 0 replies; 69+ messages in thread From: Paul Walmsley @ 2012-10-23 19:18 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-19 16:55 ` Paul Walmsley ` (2 preceding siblings ...) 2012-10-20 6:14 ` Paul Walmsley @ 2012-10-20 6:24 ` Paul Walmsley 2012-10-22 17:53 ` Kevin Hilman 3 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-20 6:24 UTC (permalink / raw) To: linux-arm-kernel 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 <khilman@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 6:24 ` Paul Walmsley @ 2012-10-22 17:53 ` Kevin Hilman 2012-10-22 20:44 ` Kevin Hilman 0 siblings, 1 reply; 69+ messages in thread From: Kevin Hilman @ 2012-10-22 17:53 UTC (permalink / raw) To: linux-arm-kernel Paul Walmsley <paul@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 <khilman@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-22 17:53 ` Kevin Hilman @ 2012-10-22 20:44 ` Kevin Hilman 0 siblings, 0 replies; 69+ messages in thread From: Kevin Hilman @ 2012-10-22 20:44 UTC (permalink / raw) To: linux-arm-kernel Kevin Hilman <khilman@deeprootsystems.com> writes: > Paul Walmsley <paul@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 <khilman@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-omap&m=135093801330065&w=2 I'll be adding this to my PM-related fixes queue for v3.7-rc3. Kevin ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-18 5:20 OMAP baseline test results for v3.7-rc1 Paul Walmsley 2012-10-18 6:48 ` Paul Walmsley 2012-10-19 16:55 ` Paul Walmsley @ 2012-10-20 14:11 ` Richard Cochran 2012-10-20 16:27 ` Paul Walmsley 2012-10-20 17:20 ` Paul Walmsley 3 siblings, 1 reply; 69+ messages in thread From: Richard Cochran @ 2012-10-20 14:11 UTC (permalink / raw) To: linux-arm-kernel On Thu, Oct 18, 2012 at 05:20:46AM +0000, 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 \b\b\b 0 U-Boot# tftp 81000000 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: 0x81000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################ done Bytes transferred = 3822248 (3a52a8 hex) U-Boot# tftp 82000000 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: 0x82000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############# done Bytes transferred = 2059309 (1f6c2d hex) U-Boot# tftp 80000000 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: 0x80000000 Loading: # done Bytes transferred = 4391 (1127 hex) U-Boot# bootm 81000000 - 80000000 ## Booting kernel from Legacy Image at 81000000 ... 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 80000000 Booting using the fdt blob at 0x80000000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe66000, end 8fe6a126 ... OK Starting kernel ... ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 14:11 ` Richard Cochran @ 2012-10-20 16:27 ` Paul Walmsley 2012-10-20 18:01 ` Richard Cochran 2012-10-21 7:35 ` Richard Cochran 0 siblings, 2 replies; 69+ messages in thread From: Paul Walmsley @ 2012-10-20 16:27 UTC (permalink / raw) To: linux-arm-kernel Hi Richard On Sat, 20 Oct 2012, Richard Cochran wrote: > On Thu, Oct 18, 2012 at 05:20:46AM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 16:27 ` Paul Walmsley @ 2012-10-20 18:01 ` Richard Cochran 2012-10-20 18:12 ` Paul Walmsley 2012-10-21 7:35 ` Richard Cochran 1 sibling, 1 reply; 69+ messages in thread From: Richard Cochran @ 2012-10-20 18:01 UTC (permalink / raw) To: linux-arm-kernel On Sat, Oct 20, 2012 at 04:27:19PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 18:01 ` Richard Cochran @ 2012-10-20 18:12 ` Paul Walmsley 2012-10-20 18:37 ` Richard Cochran 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-20 18:12 UTC (permalink / raw) To: linux-arm-kernel On Sat, 20 Oct 2012, Richard Cochran wrote: > On Sat, Oct 20, 2012 at 04:27:19PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 18:12 ` Paul Walmsley @ 2012-10-20 18:37 ` Richard Cochran 2012-10-20 18:58 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Richard Cochran @ 2012-10-20 18:37 UTC (permalink / raw) To: linux-arm-kernel On Sat, Oct 20, 2012 at 06:12:35PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 18:37 ` Richard Cochran @ 2012-10-20 18:58 ` Paul Walmsley 2012-10-21 13:51 ` Matt Porter 0 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-20 18:58 UTC (permalink / raw) To: linux-arm-kernel On Sat, 20 Oct 2012, Richard Cochran wrote: > On Sat, Oct 20, 2012 at 06:12:35PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 18:58 ` Paul Walmsley @ 2012-10-21 13:51 ` Matt Porter 2012-10-21 16:26 ` Paul Walmsley 2012-10-22 21:56 ` Kevin Hilman 0 siblings, 2 replies; 69+ messages in thread From: Matt Porter @ 2012-10-21 13:51 UTC (permalink / raw) To: linux-arm-kernel On Sat, Oct 20, 2012 at 06:58:10PM +0000, Paul Walmsley wrote: > On Sat, 20 Oct 2012, Richard Cochran wrote: > > > On Sat, Oct 20, 2012 at 06:12:35PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-21 13:51 ` Matt Porter @ 2012-10-21 16:26 ` Paul Walmsley 2012-10-22 21:56 ` Kevin Hilman 1 sibling, 0 replies; 69+ messages in thread From: Paul Walmsley @ 2012-10-21 16:26 UTC (permalink / raw) To: linux-arm-kernel On Sun, 21 Oct 2012, Matt Porter wrote: > On Sat, Oct 20, 2012 at 06:58:10PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-21 13:51 ` Matt Porter 2012-10-21 16:26 ` Paul Walmsley @ 2012-10-22 21:56 ` Kevin Hilman 1 sibling, 0 replies; 69+ messages in thread From: Kevin Hilman @ 2012-10-22 21:56 UTC (permalink / raw) To: linux-arm-kernel Matt Porter <mporter@ti.com> writes: > On Sat, Oct 20, 2012 at 06:58:10PM +0000, Paul Walmsley wrote: >> On Sat, 20 Oct 2012, Richard Cochran wrote: >> >> > On Sat, Oct 20, 2012 at 06:12:35PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 16:27 ` Paul Walmsley 2012-10-20 18:01 ` Richard Cochran @ 2012-10-21 7:35 ` Richard Cochran 2012-10-21 8:23 ` Paul Walmsley 2012-10-21 12:29 ` Mohammed, Afzal 1 sibling, 2 replies; 69+ messages in thread From: Richard Cochran @ 2012-10-21 7:35 UTC (permalink / raw) To: linux-arm-kernel On Sat, Oct 20, 2012 at 04:27:19PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-21 7:35 ` Richard Cochran @ 2012-10-21 8:23 ` Paul Walmsley 2012-10-21 11:44 ` Richard Cochran 2012-10-21 12:29 ` Mohammed, Afzal 1 sibling, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-21 8:23 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-21 8:23 ` Paul Walmsley @ 2012-10-21 11:44 ` Richard Cochran 2012-10-21 16:24 ` Paul Walmsley 0 siblings, 1 reply; 69+ messages in thread From: Richard Cochran @ 2012-10-21 11:44 UTC (permalink / raw) To: linux-arm-kernel On Sun, Oct 21, 2012 at 08:23:35AM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-21 11:44 ` Richard Cochran @ 2012-10-21 16:24 ` Paul Walmsley 0 siblings, 0 replies; 69+ messages in thread From: Paul Walmsley @ 2012-10-21 16:24 UTC (permalink / raw) To: linux-arm-kernel On Sun, 21 Oct 2012, Richard Cochran wrote: > On Sun, Oct 21, 2012 at 08:23:35AM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-21 7:35 ` Richard Cochran 2012-10-21 8:23 ` Paul Walmsley @ 2012-10-21 12:29 ` Mohammed, Afzal 2012-10-21 12:36 ` Richard Cochran 1 sibling, 1 reply; 69+ messages in thread From: Mohammed, Afzal @ 2012-10-21 12:29 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-21 12:29 ` Mohammed, Afzal @ 2012-10-21 12:36 ` Richard Cochran 0 siblings, 0 replies; 69+ messages in thread From: Richard Cochran @ 2012-10-21 12:36 UTC (permalink / raw) To: linux-arm-kernel On Sun, Oct 21, 2012 at 12:29:26PM +0000, 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-18 5:20 OMAP baseline test results for v3.7-rc1 Paul Walmsley ` (2 preceding siblings ...) 2012-10-20 14:11 ` Richard Cochran @ 2012-10-20 17:20 ` Paul Walmsley 2012-10-22 16:13 ` Tero Kristo 3 siblings, 1 reply; 69+ messages in thread From: Paul Walmsley @ 2012-10-20 17:20 UTC (permalink / raw) To: linux-arm-kernel 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 <svenkatr@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* OMAP baseline test results for v3.7-rc1 2012-10-20 17:20 ` Paul Walmsley @ 2012-10-22 16:13 ` Tero Kristo 0 siblings, 0 replies; 69+ messages in thread From: Tero Kristo @ 2012-10-22 16:13 UTC (permalink / raw) To: linux-arm-kernel On Sat, 2012-10-20 at 17:20 +0000, 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 <svenkatr@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2012-11-06 16:13 UTC | newest] Thread overview: 69+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-10-18 5:20 OMAP baseline test results for v3.7-rc1 Paul Walmsley 2012-10-18 6:48 ` Paul Walmsley 2012-10-18 8:37 ` Tero Kristo 2012-10-18 8:48 ` Santosh Shilimkar 2012-10-20 17:30 ` Paul Walmsley 2012-10-19 16:55 ` Paul Walmsley 2012-10-19 17:01 ` Felipe Balbi 2012-10-19 17:56 ` Paul Walmsley 2012-10-19 18:10 ` Felipe Balbi 2012-10-19 19:03 ` Aaro Koskinen 2012-10-19 19:01 ` Felipe Balbi 2012-10-19 19:38 ` Aaro Koskinen 2012-10-22 17:21 ` Kevin Hilman 2012-10-22 20:43 ` Kevin Hilman 2012-10-20 6:14 ` Paul Walmsley 2012-10-22 16:12 ` Jean Pihet 2012-10-22 17:26 ` Jean Pihet 2012-10-23 19:19 ` Paul Walmsley 2012-10-23 19:23 ` Jean Pihet 2012-10-25 10:12 ` Felipe Balbi 2012-10-26 20:15 ` Felipe Balbi 2012-10-26 22:03 ` Paul Walmsley 2012-10-29 20:00 ` Felipe Balbi 2012-10-30 12:17 ` Paul Walmsley 2012-10-30 12:32 ` Felipe Balbi 2012-10-30 12:50 ` Paul Walmsley 2012-10-30 12:54 ` Felipe Balbi 2012-10-30 13:17 ` Paul Walmsley 2012-10-30 14:04 ` Paul Walmsley 2012-10-31 8:34 ` Jean Pihet 2012-10-31 9:05 ` Rafael J. Wysocki 2012-10-31 8:22 ` Jean Pihet 2012-10-31 10:49 ` Kevin Hilman 2012-10-31 21:11 ` Jean Pihet 2012-11-01 2:44 ` Paul Walmsley 2012-11-01 7:51 ` Jean Pihet 2012-11-03 21:39 ` Jean Pihet 2012-11-05 3:15 ` Paul Walmsley 2012-11-05 9:26 ` Jean Pihet 2012-11-06 0:01 ` Kevin Hilman 2012-11-06 9:27 ` Jean Pihet 2012-11-06 16:13 ` Paul Walmsley 2012-11-06 10:06 ` Shubhrajyoti Datta 2012-10-30 4:16 ` Paul Walmsley 2012-10-30 8:54 ` Jean Pihet 2012-10-30 11:23 ` Paul Walmsley 2012-10-31 8:18 ` Jean Pihet 2012-10-23 19:17 ` Kevin Hilman 2012-10-23 19:18 ` Paul Walmsley 2012-10-20 6:24 ` Paul Walmsley 2012-10-22 17:53 ` Kevin Hilman 2012-10-22 20:44 ` Kevin Hilman 2012-10-20 14:11 ` Richard Cochran 2012-10-20 16:27 ` Paul Walmsley 2012-10-20 18:01 ` Richard Cochran 2012-10-20 18:12 ` Paul Walmsley 2012-10-20 18:37 ` Richard Cochran 2012-10-20 18:58 ` Paul Walmsley 2012-10-21 13:51 ` Matt Porter 2012-10-21 16:26 ` Paul Walmsley 2012-10-22 21:56 ` Kevin Hilman 2012-10-21 7:35 ` Richard Cochran 2012-10-21 8:23 ` Paul Walmsley 2012-10-21 11:44 ` Richard Cochran 2012-10-21 16:24 ` Paul Walmsley 2012-10-21 12:29 ` Mohammed, Afzal 2012-10-21 12:36 ` Richard Cochran 2012-10-20 17:20 ` Paul Walmsley 2012-10-22 16:13 ` Tero Kristo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).