All of lore.kernel.org
 help / color / mirror / Atom feed
* OMAP baseline test results for v3.7-rc1
@ 2012-10-18  5:20 ` Paul Walmsley
  0 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-18  5:20 UTC (permalink / raw)
  To: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-18  5:20 ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-18  5:20 ` Paul Walmsley
@ 2012-10-18  6:48   ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-18  6:48 UTC (permalink / raw)
  To: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-18  6:48   ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-18  6:48   ` Paul Walmsley
@ 2012-10-18  8:37     ` Tero Kristo
  -1 siblings, 0 replies; 138+ messages in thread
From: Tero Kristo @ 2012-10-18  8:37 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, 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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-18  8:37     ` Tero Kristo
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-18  8:37     ` Tero Kristo
@ 2012-10-18  8:48       ` Santosh Shilimkar
  -1 siblings, 0 replies; 138+ messages in thread
From: Santosh Shilimkar @ 2012-10-18  8:48 UTC (permalink / raw)
  To: t-kristo, Paul Walmsley; +Cc: linux-omap, 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@vger.kernel.org/msg78045.html



^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-18  8:48       ` Santosh Shilimkar
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-18  5:20 ` Paul Walmsley
@ 2012-10-19 16:55   ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-19 16:55 UTC (permalink / raw)
  To: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-19 16:55   ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-19 16:55   ` Paul Walmsley
@ 2012-10-19 17:01     ` Felipe Balbi
  -1 siblings, 0 replies; 138+ messages in thread
From: Felipe Balbi @ 2012-10-19 17:01 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-19 17:01     ` Felipe Balbi
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-19 17:01     ` Felipe Balbi
@ 2012-10-19 17:56       ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-19 17:56 UTC (permalink / raw)
  To: Felipe Balbi; +Cc: linux-omap, 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@nozomi:~$ egrep '(version 3\.|timeout waiting)' 3530es3beagle_log.txt 
[    0.000000] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[    0.000000] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[   22.710418] omap_i2c omap_i2c.1: timeout waiting for bus ready
[   23.726074] omap_i2c omap_i2c.1: timeout waiting for bus ready
[    0.000000] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[   22.804351] omap_i2c omap_i2c.1: timeout waiting for bus ready
[   23.819976] omap_i2c omap_i2c.1: timeout waiting for bus ready
[    0.000000] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[   22.805419] omap_i2c omap_i2c.1: timeout waiting for bus ready
[   23.821044] omap_i2c omap_i2c.1: timeout waiting for bus ready
[    0.000000] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[   22.820648] omap_i2c omap_i2c.1: timeout waiting for bus ready
[   23.836273] omap_i2c omap_i2c.1: timeout waiting for bus ready
[    0.000000] Linux version 3.7.0-rc1 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:58:00 MDT 2012
[   22.858978] omap_i2c omap_i2c.1: timeout waiting for bus ready
[   23.874603] omap_i2c omap_i2c.1: timeout waiting for bus ready
[    0.000000] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012
[    0.000000] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012
[    0.000000] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012
[    0.000000] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012
[    0.000000] Linux version 3.6.0 (paul@nozomi) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Wed Oct 17 20:42:23 MDT 2012


^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-19 17:56       ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-19 17:56       ` Paul Walmsley
@ 2012-10-19 18:10         ` Felipe Balbi
  -1 siblings, 0 replies; 138+ messages in thread
From: Felipe Balbi @ 2012-10-19 18:10 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: Felipe Balbi, linux-omap, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-19 18:10         ` Felipe Balbi
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-19 19:03     ` Aaro Koskinen
@ 2012-10-19 19:01       ` Felipe Balbi
  -1 siblings, 0 replies; 138+ messages in thread
From: Felipe Balbi @ 2012-10-19 19:01 UTC (permalink / raw)
  To: Aaro Koskinen; +Cc: Paul Walmsley, linux-omap, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-19 19:01       ` Felipe Balbi
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-19 16:55   ` Paul Walmsley
@ 2012-10-19 19:03     ` Aaro Koskinen
  -1 siblings, 0 replies; 138+ messages in thread
From: Aaro Koskinen @ 2012-10-19 19:03 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-19 19:03     ` Aaro Koskinen
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-19 19:01       ` Felipe Balbi
@ 2012-10-19 19:38         ` Aaro Koskinen
  -1 siblings, 0 replies; 138+ messages in thread
From: Aaro Koskinen @ 2012-10-19 19:38 UTC (permalink / raw)
  To: Felipe Balbi; +Cc: Paul Walmsley, linux-omap, 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@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@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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-19 19:38         ` Aaro Koskinen
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-19 16:55   ` Paul Walmsley
@ 2012-10-20  6:14     ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-20  6:14 UTC (permalink / raw)
  To: jean.pihet; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20  6:14     ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-19 16:55   ` Paul Walmsley
@ 2012-10-20  6:24     ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-20  6:24 UTC (permalink / raw)
  To: khilman; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20  6:24     ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-18  5:20 ` Paul Walmsley
@ 2012-10-20 14:11   ` Richard Cochran
  -1 siblings, 0 replies; 138+ messages in thread
From: Richard Cochran @ 2012-10-20 14:11 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20 14:11   ` Richard Cochran
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20 14:11   ` Richard Cochran
@ 2012-10-20 16:27     ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-20 16:27 UTC (permalink / raw)
  To: Richard Cochran; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20 16:27     ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-18  5:20 ` Paul Walmsley
@ 2012-10-20 17:20   ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-20 17:20 UTC (permalink / raw)
  To: Venkatraman S
  Cc: linux-omap, linux-arm-kernel, khilman, Felipe Balbi, Chris Ball,
	linux-mmc

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20 17:20   ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-18  8:48       ` Santosh Shilimkar
@ 2012-10-20 17:30         ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-20 17:30 UTC (permalink / raw)
  To: Santosh Shilimkar; +Cc: t-kristo, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20 17:30         ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20 16:27     ` Paul Walmsley
@ 2012-10-20 18:01       ` Richard Cochran
  -1 siblings, 0 replies; 138+ messages in thread
From: Richard Cochran @ 2012-10-20 18:01 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20 18:01       ` Richard Cochran
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20 18:01       ` Richard Cochran
@ 2012-10-20 18:12         ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-20 18:12 UTC (permalink / raw)
  To: Richard Cochran; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20 18:12         ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20 18:12         ` Paul Walmsley
@ 2012-10-20 18:37           ` Richard Cochran
  -1 siblings, 0 replies; 138+ messages in thread
From: Richard Cochran @ 2012-10-20 18:37 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20 18:37           ` Richard Cochran
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20 18:37           ` Richard Cochran
@ 2012-10-20 18:58             ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-20 18:58 UTC (permalink / raw)
  To: Richard Cochran; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-20 18:58             ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20 16:27     ` Paul Walmsley
@ 2012-10-21  7:35       ` Richard Cochran
  -1 siblings, 0 replies; 138+ messages in thread
From: Richard Cochran @ 2012-10-21  7:35 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-21  7:35       ` Richard Cochran
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-21  7:35       ` Richard Cochran
@ 2012-10-21  8:23         ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-21  8:23 UTC (permalink / raw)
  To: Richard Cochran; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-21  8:23         ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-21  8:23         ` Paul Walmsley
@ 2012-10-21 11:44           ` Richard Cochran
  -1 siblings, 0 replies; 138+ messages in thread
From: Richard Cochran @ 2012-10-21 11:44 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-21 11:44           ` Richard Cochran
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* RE: OMAP baseline test results for v3.7-rc1
  2012-10-21  7:35       ` Richard Cochran
@ 2012-10-21 12:29         ` Mohammed, Afzal
  -1 siblings, 0 replies; 138+ messages in thread
From: Mohammed, Afzal @ 2012-10-21 12:29 UTC (permalink / raw)
  To: Richard Cochran, Paul Walmsley; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-21 12:29         ` Mohammed, Afzal
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-21 12:29         ` Mohammed, Afzal
@ 2012-10-21 12:36           ` Richard Cochran
  -1 siblings, 0 replies; 138+ messages in thread
From: Richard Cochran @ 2012-10-21 12:36 UTC (permalink / raw)
  To: Mohammed, Afzal; +Cc: Paul Walmsley, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-21 12:36           ` Richard Cochran
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20 18:58             ` Paul Walmsley
@ 2012-10-21 13:51               ` Matt Porter
  -1 siblings, 0 replies; 138+ messages in thread
From: Matt Porter @ 2012-10-21 13:51 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: Richard Cochran, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-21 13:51               ` Matt Porter
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-21 11:44           ` Richard Cochran
@ 2012-10-21 16:24             ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-21 16:24 UTC (permalink / raw)
  To: Richard Cochran; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-21 16:24             ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-21 13:51               ` Matt Porter
@ 2012-10-21 16:26                 ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-21 16:26 UTC (permalink / raw)
  To: Matt Porter; +Cc: Richard Cochran, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-21 16:26                 ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20  6:14     ` Paul Walmsley
@ 2012-10-22 16:12       ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-10-22 16:12 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-22 16:12       ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20 17:20   ` Paul Walmsley
@ 2012-10-22 16:13     ` Tero Kristo
  -1 siblings, 0 replies; 138+ messages in thread
From: Tero Kristo @ 2012-10-22 16:13 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: Venkatraman S, khilman, linux-omap, linux-mmc, Felipe Balbi,
	Chris Ball, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-22 16:13     ` Tero Kristo
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-19 19:38         ` Aaro Koskinen
@ 2012-10-22 17:21           ` Kevin Hilman
  -1 siblings, 0 replies; 138+ messages in thread
From: Kevin Hilman @ 2012-10-22 17:21 UTC (permalink / raw)
  To: Aaro Koskinen; +Cc: Felipe Balbi, Paul Walmsley, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-22 17:21           ` Kevin Hilman
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-22 16:12       ` Jean Pihet
@ 2012-10-22 17:26         ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-10-22 17:26 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-22 17:26         ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-20  6:24     ` Paul Walmsley
@ 2012-10-22 17:53       ` Kevin Hilman
  -1 siblings, 0 replies; 138+ messages in thread
From: Kevin Hilman @ 2012-10-22 17:53 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-22 17:53       ` Kevin Hilman
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-22 17:21           ` Kevin Hilman
@ 2012-10-22 20:43             ` Kevin Hilman
  -1 siblings, 0 replies; 138+ messages in thread
From: Kevin Hilman @ 2012-10-22 20:43 UTC (permalink / raw)
  To: Aaro Koskinen; +Cc: Felipe Balbi, Paul Walmsley, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-22 20:43             ` Kevin Hilman
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-22 17:53       ` Kevin Hilman
@ 2012-10-22 20:44         ` Kevin Hilman
  -1 siblings, 0 replies; 138+ messages in thread
From: Kevin Hilman @ 2012-10-22 20:44 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-22 20:44         ` Kevin Hilman
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-21 13:51               ` Matt Porter
@ 2012-10-22 21:56                 ` Kevin Hilman
  -1 siblings, 0 replies; 138+ messages in thread
From: Kevin Hilman @ 2012-10-22 21:56 UTC (permalink / raw)
  To: Matt Porter; +Cc: Paul Walmsley, Richard Cochran, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-22 21:56                 ` Kevin Hilman
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-22 16:12       ` Jean Pihet
@ 2012-10-23 19:17         ` Kevin Hilman
  -1 siblings, 0 replies; 138+ messages in thread
From: Kevin Hilman @ 2012-10-23 19:17 UTC (permalink / raw)
  To: Jean Pihet
  Cc: Paul Walmsley, balbi, aaro.koskinen, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-23 19:17         ` Kevin Hilman
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-22 16:12       ` Jean Pihet
@ 2012-10-23 19:18         ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-23 19:18 UTC (permalink / raw)
  To: Jean Pihet; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-23 19:18         ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-22 17:26         ` Jean Pihet
@ 2012-10-23 19:19           ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-23 19:19 UTC (permalink / raw)
  To: Jean Pihet; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-23 19:19           ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-23 19:19           ` Paul Walmsley
@ 2012-10-23 19:23             ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-10-23 19:23 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-23 19:23             ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-23 19:23             ` Jean Pihet
@ 2012-10-25 10:12               ` Felipe Balbi
  -1 siblings, 0 replies; 138+ messages in thread
From: Felipe Balbi @ 2012-10-25 10:12 UTC (permalink / raw)
  To: Jean Pihet
  Cc: Paul Walmsley, balbi, aaro.koskinen, linux-omap,
	linux-arm-kernel, khilman

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-25 10:12               ` Felipe Balbi
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-25 10:12               ` Felipe Balbi
@ 2012-10-26 20:15                 ` Felipe Balbi
  -1 siblings, 0 replies; 138+ messages in thread
From: Felipe Balbi @ 2012-10-26 20:15 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Jean Pihet, Paul Walmsley, aaro.koskinen, linux-omap,
	linux-arm-kernel, khilman

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-26 20:15                 ` Felipe Balbi
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-26 20:15                 ` Felipe Balbi
@ 2012-10-26 22:03                   ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-26 22:03 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Jean Pihet, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-26 22:03                   ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-26 22:03                   ` Paul Walmsley
@ 2012-10-29 20:00                     ` Felipe Balbi
  -1 siblings, 0 replies; 138+ messages in thread
From: Felipe Balbi @ 2012-10-29 20:00 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: Felipe Balbi, Jean Pihet, aaro.koskinen, linux-omap,
	linux-arm-kernel, khilman

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-29 20:00                     ` Felipe Balbi
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-23 19:23             ` Jean Pihet
@ 2012-10-30  4:16               ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-30  4:16 UTC (permalink / raw)
  To: Jean Pihet; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-30  4:16               ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30  4:16               ` Paul Walmsley
@ 2012-10-30  8:54                 ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-10-30  8:54 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-30  8:54                 ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30  8:54                 ` Jean Pihet
@ 2012-10-30 11:23                   ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-30 11:23 UTC (permalink / raw)
  To: Jean Pihet; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-30 11:23                   ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-29 20:00                     ` Felipe Balbi
@ 2012-10-30 12:17                       ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-30 12:17 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Jean Pihet, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

[-- Attachment #1: Type: TEXT/PLAIN, Size: 63842 bytes --]

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@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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-30 12:17                       ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30 12:17                       ` Paul Walmsley
@ 2012-10-30 12:32                         ` Felipe Balbi
  -1 siblings, 0 replies; 138+ messages in thread
From: Felipe Balbi @ 2012-10-30 12:32 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: Felipe Balbi, Jean Pihet, aaro.koskinen, linux-omap,
	linux-arm-kernel, khilman

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-30 12:32                         ` Felipe Balbi
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30 12:32                         ` Felipe Balbi
@ 2012-10-30 12:50                           ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-30 12:50 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Jean Pihet, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-30 12:50                           ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30 12:50                           ` Paul Walmsley
@ 2012-10-30 12:54                             ` Felipe Balbi
  -1 siblings, 0 replies; 138+ messages in thread
From: Felipe Balbi @ 2012-10-30 12:54 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: Felipe Balbi, Jean Pihet, aaro.koskinen, linux-omap,
	linux-arm-kernel, khilman

[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-30 12:54                             ` Felipe Balbi
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30 12:54                             ` Felipe Balbi
@ 2012-10-30 13:17                               ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-30 13:17 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Jean Pihet, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-30 13:17                               ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30 13:17                               ` Paul Walmsley
@ 2012-10-30 14:04                                 ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-10-30 14:04 UTC (permalink / raw)
  To: Felipe Balbi, Jean Pihet
  Cc: aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-30 14:04                                 ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30 11:23                   ` Paul Walmsley
@ 2012-10-31  8:18                     ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-10-31  8:18 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-31  8:18                     ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30 13:17                               ` Paul Walmsley
@ 2012-10-31  8:22                                 ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-10-31  8:22 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: Felipe Balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-31  8:22                                 ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-30 14:04                                 ` Paul Walmsley
@ 2012-10-31  8:34                                   ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-10-31  8:34 UTC (permalink / raw)
  To: Paul Walmsley, rjw
  Cc: Felipe Balbi, aaro.koskinen, linux-omap, linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-31  8:34                                   ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-31  8:34                                   ` Jean Pihet
@ 2012-10-31  9:05                                     ` Rafael J. Wysocki
  -1 siblings, 0 replies; 138+ messages in thread
From: Rafael J. Wysocki @ 2012-10-31  9:05 UTC (permalink / raw)
  To: Jean Pihet
  Cc: Paul Walmsley, Felipe Balbi, aaro.koskinen, linux-omap,
	linux-arm-kernel, khilman

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-31  9:05                                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-31  8:22                                 ` Jean Pihet
@ 2012-10-31 10:49                                   ` Kevin Hilman
  -1 siblings, 0 replies; 138+ messages in thread
From: Kevin Hilman @ 2012-10-31 10:49 UTC (permalink / raw)
  To: Jean Pihet
  Cc: Paul Walmsley, Felipe Balbi, aaro.koskinen, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-31 10:49                                   ` Kevin Hilman
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-31 10:49                                   ` Kevin Hilman
@ 2012-10-31 21:11                                     ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-10-31 21:11 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: Paul Walmsley, Felipe Balbi, aaro.koskinen, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-10-31 21:11                                     ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-10-31 21:11                                     ` Jean Pihet
@ 2012-11-01  2:44                                       ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-11-01  2:44 UTC (permalink / raw)
  To: Jean Pihet
  Cc: Kevin Hilman, Felipe Balbi, aaro.koskinen, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-11-01  2:44                                       ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-11-01  2:44                                       ` Paul Walmsley
@ 2012-11-01  7:51                                         ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-11-01  7:51 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: Kevin Hilman, Felipe Balbi, aaro.koskinen, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-11-01  7:51                                         ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-11-01  7:51                                         ` Jean Pihet
@ 2012-11-03 21:39                                           ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-11-03 21:39 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: Kevin Hilman, Felipe Balbi, aaro.koskinen, linux-omap, 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@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@beagleboard:~# hwclock -s
root@beagleboard:~# cat
/sys/devices/platform/omap_i2c.1/i2c-1/1-004b/twl_rtc/rtc/rtc0/date
2011-07-22
root@beagleboard:~# cat
/sys/devices/platform/omap_i2c.1/i2c-1/1-004b/twl_rtc/rtc/rtc0/time
02:12:00
root@beagleboard:~#

>>
>>
>> - Paul

More investigation on-going, so more to come!

Regards,
Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-11-03 21:39                                           ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-11-03 21:39                                           ` Jean Pihet
@ 2012-11-05  3:15                                             ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-11-05  3:15 UTC (permalink / raw)
  To: Jean Pihet
  Cc: Kevin Hilman, Felipe Balbi, aaro.koskinen, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-11-05  3:15                                             ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-11-05  3:15                                             ` Paul Walmsley
@ 2012-11-05  9:26                                               ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-11-05  9:26 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: Kevin Hilman, Felipe Balbi, aaro.koskinen, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-11-05  9:26                                               ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-11-05  9:26                                               ` Jean Pihet
@ 2012-11-06  0:01                                                 ` Kevin Hilman
  -1 siblings, 0 replies; 138+ messages in thread
From: Kevin Hilman @ 2012-11-06  0:01 UTC (permalink / raw)
  To: Jean Pihet
  Cc: Paul Walmsley, Felipe Balbi, aaro.koskinen, linux-omap, 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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-11-06  0:01                                                 ` Kevin Hilman
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-11-06  0:01                                                 ` Kevin Hilman
@ 2012-11-06  9:27                                                   ` Jean Pihet
  -1 siblings, 0 replies; 138+ messages in thread
From: Jean Pihet @ 2012-11-06  9:27 UTC (permalink / raw)
  To: Kevin Hilman, Paul Walmsley
  Cc: Felipe Balbi, aaro.koskinen, linux-omap, linux-arm-kernel,
	Benoit Cousson

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-11-06  9:27                                                   ` Jean Pihet
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-11-06  0:01                                                 ` Kevin Hilman
@ 2012-11-06 10:06                                                   ` Shubhrajyoti Datta
  -1 siblings, 0 replies; 138+ messages in thread
From: Shubhrajyoti Datta @ 2012-11-06 10:06 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: Jean Pihet, Paul Walmsley, Felipe Balbi, aaro.koskinen,
	linux-omap, 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@vger.kernel.org/msg79841.html

^ permalink raw reply	[flat|nested] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-11-06 10:06                                                   ` Shubhrajyoti Datta
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

* Re: OMAP baseline test results for v3.7-rc1
  2012-11-06  9:27                                                   ` Jean Pihet
@ 2012-11-06 16:13                                                     ` Paul Walmsley
  -1 siblings, 0 replies; 138+ messages in thread
From: Paul Walmsley @ 2012-11-06 16:13 UTC (permalink / raw)
  To: Jean Pihet
  Cc: Kevin Hilman, Felipe Balbi, aaro.koskinen, linux-omap,
	linux-arm-kernel, Benoit Cousson

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] 138+ messages in thread

* OMAP baseline test results for v3.7-rc1
@ 2012-11-06 16:13                                                     ` Paul Walmsley
  0 siblings, 0 replies; 138+ 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] 138+ messages in thread

end of thread, other threads:[~2012-11-06 16:13 UTC | newest]

Thread overview: 138+ 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  5:20 ` Paul Walmsley
2012-10-18  6:48 ` Paul Walmsley
2012-10-18  6:48   ` Paul Walmsley
2012-10-18  8:37   ` Tero Kristo
2012-10-18  8:37     ` Tero Kristo
2012-10-18  8:48     ` Santosh Shilimkar
2012-10-18  8:48       ` Santosh Shilimkar
2012-10-20 17:30       ` Paul Walmsley
2012-10-20 17:30         ` Paul Walmsley
2012-10-19 16:55 ` Paul Walmsley
2012-10-19 16:55   ` Paul Walmsley
2012-10-19 17:01   ` Felipe Balbi
2012-10-19 17:01     ` Felipe Balbi
2012-10-19 17:56     ` Paul Walmsley
2012-10-19 17:56       ` Paul Walmsley
2012-10-19 18:10       ` Felipe Balbi
2012-10-19 18:10         ` Felipe Balbi
2012-10-19 19:03   ` Aaro Koskinen
2012-10-19 19:03     ` Aaro Koskinen
2012-10-19 19:01     ` Felipe Balbi
2012-10-19 19:01       ` Felipe Balbi
2012-10-19 19:38       ` Aaro Koskinen
2012-10-19 19:38         ` Aaro Koskinen
2012-10-22 17:21         ` Kevin Hilman
2012-10-22 17:21           ` Kevin Hilman
2012-10-22 20:43           ` Kevin Hilman
2012-10-22 20:43             ` Kevin Hilman
2012-10-20  6:14   ` Paul Walmsley
2012-10-20  6:14     ` Paul Walmsley
2012-10-22 16:12     ` Jean Pihet
2012-10-22 16:12       ` Jean Pihet
2012-10-22 17:26       ` Jean Pihet
2012-10-22 17:26         ` Jean Pihet
2012-10-23 19:19         ` Paul Walmsley
2012-10-23 19:19           ` Paul Walmsley
2012-10-23 19:23           ` Jean Pihet
2012-10-23 19:23             ` Jean Pihet
2012-10-25 10:12             ` Felipe Balbi
2012-10-25 10:12               ` Felipe Balbi
2012-10-26 20:15               ` Felipe Balbi
2012-10-26 20:15                 ` Felipe Balbi
2012-10-26 22:03                 ` Paul Walmsley
2012-10-26 22:03                   ` Paul Walmsley
2012-10-29 20:00                   ` Felipe Balbi
2012-10-29 20:00                     ` Felipe Balbi
2012-10-30 12:17                     ` Paul Walmsley
2012-10-30 12:17                       ` Paul Walmsley
2012-10-30 12:32                       ` Felipe Balbi
2012-10-30 12:32                         ` Felipe Balbi
2012-10-30 12:50                         ` Paul Walmsley
2012-10-30 12:50                           ` Paul Walmsley
2012-10-30 12:54                           ` Felipe Balbi
2012-10-30 12:54                             ` Felipe Balbi
2012-10-30 13:17                             ` Paul Walmsley
2012-10-30 13:17                               ` Paul Walmsley
2012-10-30 14:04                               ` Paul Walmsley
2012-10-30 14:04                                 ` Paul Walmsley
2012-10-31  8:34                                 ` Jean Pihet
2012-10-31  8:34                                   ` Jean Pihet
2012-10-31  9:05                                   ` Rafael J. Wysocki
2012-10-31  9:05                                     ` Rafael J. Wysocki
2012-10-31  8:22                               ` Jean Pihet
2012-10-31  8:22                                 ` Jean Pihet
2012-10-31 10:49                                 ` Kevin Hilman
2012-10-31 10:49                                   ` Kevin Hilman
2012-10-31 21:11                                   ` Jean Pihet
2012-10-31 21:11                                     ` Jean Pihet
2012-11-01  2:44                                     ` Paul Walmsley
2012-11-01  2:44                                       ` Paul Walmsley
2012-11-01  7:51                                       ` Jean Pihet
2012-11-01  7:51                                         ` Jean Pihet
2012-11-03 21:39                                         ` Jean Pihet
2012-11-03 21:39                                           ` Jean Pihet
2012-11-05  3:15                                           ` Paul Walmsley
2012-11-05  3:15                                             ` Paul Walmsley
2012-11-05  9:26                                             ` Jean Pihet
2012-11-05  9:26                                               ` Jean Pihet
2012-11-06  0:01                                               ` Kevin Hilman
2012-11-06  0:01                                                 ` Kevin Hilman
2012-11-06  9:27                                                 ` Jean Pihet
2012-11-06  9:27                                                   ` Jean Pihet
2012-11-06 16:13                                                   ` Paul Walmsley
2012-11-06 16:13                                                     ` Paul Walmsley
2012-11-06 10:06                                                 ` Shubhrajyoti Datta
2012-11-06 10:06                                                   ` Shubhrajyoti Datta
2012-10-30  4:16             ` Paul Walmsley
2012-10-30  4:16               ` Paul Walmsley
2012-10-30  8:54               ` Jean Pihet
2012-10-30  8:54                 ` Jean Pihet
2012-10-30 11:23                 ` Paul Walmsley
2012-10-30 11:23                   ` Paul Walmsley
2012-10-31  8:18                   ` Jean Pihet
2012-10-31  8:18                     ` Jean Pihet
2012-10-23 19:17       ` Kevin Hilman
2012-10-23 19:17         ` Kevin Hilman
2012-10-23 19:18       ` Paul Walmsley
2012-10-23 19:18         ` Paul Walmsley
2012-10-20  6:24   ` Paul Walmsley
2012-10-20  6:24     ` Paul Walmsley
2012-10-22 17:53     ` Kevin Hilman
2012-10-22 17:53       ` Kevin Hilman
2012-10-22 20:44       ` Kevin Hilman
2012-10-22 20:44         ` Kevin Hilman
2012-10-20 14:11 ` Richard Cochran
2012-10-20 14:11   ` Richard Cochran
2012-10-20 16:27   ` Paul Walmsley
2012-10-20 16:27     ` Paul Walmsley
2012-10-20 18:01     ` Richard Cochran
2012-10-20 18:01       ` Richard Cochran
2012-10-20 18:12       ` Paul Walmsley
2012-10-20 18:12         ` Paul Walmsley
2012-10-20 18:37         ` Richard Cochran
2012-10-20 18:37           ` Richard Cochran
2012-10-20 18:58           ` Paul Walmsley
2012-10-20 18:58             ` Paul Walmsley
2012-10-21 13:51             ` Matt Porter
2012-10-21 13:51               ` Matt Porter
2012-10-21 16:26               ` Paul Walmsley
2012-10-21 16:26                 ` Paul Walmsley
2012-10-22 21:56               ` Kevin Hilman
2012-10-22 21:56                 ` Kevin Hilman
2012-10-21  7:35     ` Richard Cochran
2012-10-21  7:35       ` Richard Cochran
2012-10-21  8:23       ` Paul Walmsley
2012-10-21  8:23         ` Paul Walmsley
2012-10-21 11:44         ` Richard Cochran
2012-10-21 11:44           ` Richard Cochran
2012-10-21 16:24           ` Paul Walmsley
2012-10-21 16:24             ` Paul Walmsley
2012-10-21 12:29       ` Mohammed, Afzal
2012-10-21 12:29         ` Mohammed, Afzal
2012-10-21 12:36         ` Richard Cochran
2012-10-21 12:36           ` Richard Cochran
2012-10-20 17:20 ` Paul Walmsley
2012-10-20 17:20   ` Paul Walmsley
2012-10-22 16:13   ` Tero Kristo
2012-10-22 16:13     ` Tero Kristo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.