[PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts

[PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts

[Cory Maccarrone]

This change removes a BUG_ON for when interrupts are disabled
during an MMC request.  During boot, interrupts can be disabled
when a request is made, causing this bug to be triggered.  In reality,
there's no reason this should halt the kernel, as the driver has proved
reliable in spite of disabled interrupts, and additionally, there's
nothing in this code that would require interrupts to be enabled.

Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
---
 drivers/mmc/host/omap.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 2b28168..d98ddcf 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host,
 	mmc_omap_start_command(host, req->cmd);
 	if (host->dma_in_use)
 		omap_start_dma(host->dma_ch);
-	BUG_ON(irqs_disabled());
 }
 
 static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req)
-- 
1.7.0.4

Re: [PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts

[Tony Lindgren]

* Cory Maccarrone <darkstar6262@gmail.com> [100530 05:22]:
> This change removes a BUG_ON for when interrupts are disabled
> during an MMC request.  During boot, interrupts can be disabled
> when a request is made, causing this bug to be triggered.  In reality,
> there's no reason this should halt the kernel, as the driver has proved
> reliable in spite of disabled interrupts, and additionally, there's
> nothing in this code that would require interrupts to be enabled.
> 
> Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
> ---
>  drivers/mmc/host/omap.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index 2b28168..d98ddcf 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host,
>  	mmc_omap_start_command(host, req->cmd);
>  	if (host->dma_in_use)
>  		omap_start_dma(host->dma_ch);
> -	BUG_ON(irqs_disabled());
>  }
>  
>  static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req)

This looks safe to me.

Acked-by: Tony Lindgren <tony@atomide.com>

Re: [PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts

[Andrew Morton]

On Sat, 29 May 2010 19:27:23 -0700
Cory Maccarrone <darkstar6262@gmail.com> wrote:

> This change removes a BUG_ON for when interrupts are disabled
> during an MMC request.  During boot, interrupts can be disabled
> when a request is made, causing this bug to be triggered.  In reality,
> there's no reason this should halt the kernel, as the driver has proved
> reliable in spite of disabled interrupts, and additionally, there's
> nothing in this code that would require interrupts to be enabled.
> 
> Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
> ---
>  drivers/mmc/host/omap.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index 2b28168..d98ddcf 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host,
>  	mmc_omap_start_command(host, req->cmd);
>  	if (host->dma_in_use)
>  		omap_start_dma(host->dma_ch);
> -	BUG_ON(irqs_disabled());
>  }
>  
>  static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req)

So we need to decide whether this should be backported into 2.6.34.x
and perhaps earlier.

For that decision we'll need to know the things you didn't tell us:
Which drivers are affected?  Under which setups is it triggering?  Why
aren't lots of people reporting "hey my kernel went BUG"?

Re: [PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts

[Cory Maccarrone]

On Wed, Jun 2, 2010 at 2:05 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sat, 29 May 2010 19:27:23 -0700
> Cory Maccarrone <darkstar6262@gmail.com> wrote:
>
>> This change removes a BUG_ON for when interrupts are disabled
>> during an MMC request.  During boot, interrupts can be disabled
>> when a request is made, causing this bug to be triggered.  In reality,
>> there's no reason this should halt the kernel, as the driver has proved
>> reliable in spite of disabled interrupts, and additionally, there's
>> nothing in this code that would require interrupts to be enabled.
>>
>> Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
>> ---
>>  drivers/mmc/host/omap.c |    1 -
>>  1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
>> index 2b28168..d98ddcf 100644
>> --- a/drivers/mmc/host/omap.c
>> +++ b/drivers/mmc/host/omap.c
>> @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host,
>>       mmc_omap_start_command(host, req->cmd);
>>       if (host->dma_in_use)
>>               omap_start_dma(host->dma_ch);
>> -     BUG_ON(irqs_disabled());
>>  }
>>
>>  static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req)
>
> So we need to decide whether this should be backported into 2.6.34.x
> and perhaps earlier.
>
> For that decision we'll need to know the things you didn't tell us:
> Which drivers are affected?  Under which setups is it triggering?  Why
> aren't lots of people reporting "hey my kernel went BUG"?
>
>

The only setup I've managed to make it trigger on is on the HTC Herald
during bootup when the driver is built into the kernel (mostly because
that's all I have).  I believe it's related to the fact that on bootup
I get many timeout errors on "CMD5" while initializing the card.  Each
CMD5 timeout triggers that bug (I changed it to a WARN_ON to get it to
boot in) due to the fact that part of the timeout code involves
sending the request again.  With interrupts turned off, that BUG would
be triggered.

I can't answer the question of why other people aren't reporting this
-- I know the CMD timeouts are fairly common with this driver, and
it's only within the last few kernel releases that their triggering
the BUG started happening.  (I had only been able to test it because I
was carrying forward the MMC 16-bit patch I submitted a while ago
which only recently made it in.  I'm not sure if that's related or
not, but I need that to use the MMC-OMAP on herald.)

I imagine a better solution to this would be to fix the timeout issues
so the repeated requests aren't a problem.  But any hardware bugs that
cause a timeout during boot would cause this bug to be triggered,
which is why I'm proposing removing the BUG_ON entirely (since
everything seems to work fine anyway).

I don't know why interrupts are disabled at this point, but my limited
googling around leads me to believe the recent LOCKDEP work may be the
cause.  I couldn't find enough information on that to know for sure
though.  I do know that the bug no longer triggers after the card
initializes successfully (and presumably interrupts re-enable).

My guess is that since other people aren't reporting this problem,
it's not hugely important to backport.  A better question in that case
would be why am I seeing it?  I don't understand why interrupts would
be disabled at this point in bootup.

- Cory

Re: [PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts

[Andrew Morton]

On Wed, 2 Jun 2010 15:26:52 -0700
Cory Maccarrone <darkstar6262@gmail.com> wrote:

> On Wed, Jun 2, 2010 at 2:05 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Sat, 29 May 2010 19:27:23 -0700
> > Cory Maccarrone <darkstar6262@gmail.com> wrote:
> >
> >> This change removes a BUG_ON for when interrupts are disabled
> >> during an MMC request. __During boot, interrupts can be disabled
> >> when a request is made, causing this bug to be triggered. __In reality,
> >> there's no reason this should halt the kernel, as the driver has proved
> >> reliable in spite of disabled interrupts, and additionally, there's
> >> nothing in this code that would require interrupts to be enabled.
> >>
> >> Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
> >> ---
> >> __drivers/mmc/host/omap.c | __ __1 -
> >> __1 files changed, 0 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> >> index 2b28168..d98ddcf 100644
> >> --- a/drivers/mmc/host/omap.c
> >> +++ b/drivers/mmc/host/omap.c
> >> @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host,
> >> __ __ __ mmc_omap_start_command(host, req->cmd);
> >> __ __ __ if (host->dma_in_use)
> >> __ __ __ __ __ __ __ omap_start_dma(host->dma_ch);
> >> - __ __ BUG_ON(irqs_disabled());
> >> __}
> >>
> >> __static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req)
> >
> > So we need to decide whether this should be backported into 2.6.34.x
> > and perhaps earlier.
> >
> > For that decision we'll need to know the things you didn't tell us:
> > Which drivers are affected? __Under which setups is it triggering? __Why
> > aren't lots of people reporting "hey my kernel went BUG"?
> >
> >
> 
> The only setup I've managed to make it trigger on is on the HTC Herald
> during bootup when the driver is built into the kernel (mostly because
> that's all I have).  I believe it's related to the fact that on bootup
> I get many timeout errors on "CMD5" while initializing the card.  Each
> CMD5 timeout triggers that bug (I changed it to a WARN_ON to get it to
> boot in) due to the fact that part of the timeout code involves
> sending the request again.  With interrupts turned off, that BUG would
> be triggered.
> 
> I can't answer the question of why other people aren't reporting this
> -- I know the CMD timeouts are fairly common with this driver, and
> it's only within the last few kernel releases that their triggering
> the BUG started happening.  (I had only been able to test it because I
> was carrying forward the MMC 16-bit patch I submitted a while ago
> which only recently made it in.  I'm not sure if that's related or
> not, but I need that to use the MMC-OMAP on herald.)

Do you have one of these BUG_ON() traces handy, so we can perhaps see
where local interrupts got disabled?

> I imagine a better solution to this would be to fix the timeout issues
> so the repeated requests aren't a problem.  But any hardware bugs that
> cause a timeout during boot would cause this bug to be triggered,
> which is why I'm proposing removing the BUG_ON entirely (since
> everything seems to work fine anyway).
> 
> I don't know why interrupts are disabled at this point, but my limited
> googling around leads me to believe the recent LOCKDEP work may be the
> cause.  I couldn't find enough information on that to know for sure
> though.  I do know that the bug no longer triggers after the card
> initializes successfully (and presumably interrupts re-enable).
> 
> My guess is that since other people aren't reporting this problem,
> it's not hugely important to backport.  A better question in that case
> would be why am I seeing it?  I don't understand why interrupts would
> be disabled at this point in bootup.
> 

Yes, before removing the BUG_ON() it would be most helpful to
understand why it was added.

It was added by

: commit abfbe5f7854a083ca324282bf7e39f10bc438313
: Author:     Juha Yrjola <juha.yrjola@solidboot.com>
: AuthorDate: Wed Mar 26 16:08:57 2008 -0400
: Commit:     Pierre Ossman <drzeus@drzeus.cx>
: CommitDate: Fri Apr 18 20:05:28 2008 +0200
: 
:     MMC: OMAP: Introduce new multislot structure and change driver to use it
:     
:     Introduce new MMC multislot structure and change driver to use it.
:     
:     Note that MMC clocking is now enabled in mmc_omap_select_slot()
:     and disabled in mmc_omap_release_slot().
:     
:     Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
:     Signed-off-by: Jarkko Lavinen <jarkko.lavinen@nokia.com>
:     Signed-off-by: Carlos Eduardo Aguiar <carlos.aguiar@indt.org.br>
:     Signed-off-by: Tony Lindgren <tony@atomide.com>
:     Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

Hopefully the email still works..  Juha, do you recall why you added
the BUG_ON(irqs_disabled()) to mmc_omap_start_request()?

Re: [PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts

[Cory Maccarrone]

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

On Wed, Jun 2, 2010 at 4:30 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 2 Jun 2010 15:26:52 -0700
> Cory Maccarrone <darkstar6262@gmail.com> wrote:
>
>> On Wed, Jun 2, 2010 at 2:05 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>> > On Sat, 29 May 2010 19:27:23 -0700
>> > Cory Maccarrone <darkstar6262@gmail.com> wrote:
>> >
>> >> This change removes a BUG_ON for when interrupts are disabled
>> >> during an MMC request. __During boot, interrupts can be disabled
>> >> when a request is made, causing this bug to be triggered. __In reality,
>> >> there's no reason this should halt the kernel, as the driver has proved
>> >> reliable in spite of disabled interrupts, and additionally, there's
>> >> nothing in this code that would require interrupts to be enabled.
>> >>
>> >> Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
>> >> ---
>> >> __drivers/mmc/host/omap.c | __ __1 -
>> >> __1 files changed, 0 insertions(+), 1 deletions(-)
>> >>
>> >> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
>> >> index 2b28168..d98ddcf 100644
>> >> --- a/drivers/mmc/host/omap.c
>> >> +++ b/drivers/mmc/host/omap.c
>> >> @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host,
>> >> __ __ __ mmc_omap_start_command(host, req->cmd);
>> >> __ __ __ if (host->dma_in_use)
>> >> __ __ __ __ __ __ __ omap_start_dma(host->dma_ch);
>> >> - __ __ BUG_ON(irqs_disabled());
>> >> __}
>> >>
>> >> __static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req)
>> >
>> > So we need to decide whether this should be backported into 2.6.34.x
>> > and perhaps earlier.
>> >
>> > For that decision we'll need to know the things you didn't tell us:
>> > Which drivers are affected? __Under which setups is it triggering? __Why
>> > aren't lots of people reporting "hey my kernel went BUG"?
>> >
>> >
>>
>> The only setup I've managed to make it trigger on is on the HTC Herald
>> during bootup when the driver is built into the kernel (mostly because
>> that's all I have).  I believe it's related to the fact that on bootup
>> I get many timeout errors on "CMD5" while initializing the card.  Each
>> CMD5 timeout triggers that bug (I changed it to a WARN_ON to get it to
>> boot in) due to the fact that part of the timeout code involves
>> sending the request again.  With interrupts turned off, that BUG would
>> be triggered.
>>
>> I can't answer the question of why other people aren't reporting this
>> -- I know the CMD timeouts are fairly common with this driver, and
>> it's only within the last few kernel releases that their triggering
>> the BUG started happening.  (I had only been able to test it because I
>> was carrying forward the MMC 16-bit patch I submitted a while ago
>> which only recently made it in.  I'm not sure if that's related or
>> not, but I need that to use the MMC-OMAP on herald.)
>
> Do you have one of these BUG_ON() traces handy, so we can perhaps see
> where local interrupts got disabled?
>
>> I imagine a better solution to this would be to fix the timeout issues
>> so the repeated requests aren't a problem.  But any hardware bugs that
>> cause a timeout during boot would cause this bug to be triggered,
>> which is why I'm proposing removing the BUG_ON entirely (since
>> everything seems to work fine anyway).
>>
>> I don't know why interrupts are disabled at this point, but my limited
>> googling around leads me to believe the recent LOCKDEP work may be the
>> cause.  I couldn't find enough information on that to know for sure
>> though.  I do know that the bug no longer triggers after the card
>> initializes successfully (and presumably interrupts re-enable).
>>
>> My guess is that since other people aren't reporting this problem,
>> it's not hugely important to backport.  A better question in that case
>> would be why am I seeing it?  I don't understand why interrupts would
>> be disabled at this point in bootup.
>>
>
> Yes, before removing the BUG_ON() it would be most helpful to
> understand why it was added.
>
> It was added by
>
> : commit abfbe5f7854a083ca324282bf7e39f10bc438313
> : Author:     Juha Yrjola <juha.yrjola@solidboot.com>
> : AuthorDate: Wed Mar 26 16:08:57 2008 -0400
> : Commit:     Pierre Ossman <drzeus@drzeus.cx>
> : CommitDate: Fri Apr 18 20:05:28 2008 +0200
> :
> :     MMC: OMAP: Introduce new multislot structure and change driver to use it
> :
> :     Introduce new MMC multislot structure and change driver to use it.
> :
> :     Note that MMC clocking is now enabled in mmc_omap_select_slot()
> :     and disabled in mmc_omap_release_slot().
> :
> :     Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
> :     Signed-off-by: Jarkko Lavinen <jarkko.lavinen@nokia.com>
> :     Signed-off-by: Carlos Eduardo Aguiar <carlos.aguiar@indt.org.br>
> :     Signed-off-by: Tony Lindgren <tony@atomide.com>
> :     Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
>
> Hopefully the email still works..  Juha, do you recall why you added
> the BUG_ON(irqs_disabled()) to mmc_omap_start_request()?
>

I can only get the last screenful of output from the BUG, since I
don't have serial debugging capabilities:

Exception stack(0xc3c25d20 to 0xc3c25d68)
5d20: 00000032 c02ac86a c3c25d5c 00000000 c32a9a00 00000000 c3c77f0c 00000005
5d40: 00000001 00000000 00000001 c3c43878 00000000 c3c25d68 c0028be0 c0028be4
5d60: 60000093 ffffffff
[<c0025a28>] (__dabt_svc+0x48/0x60) from [<c0028be4]> (__bug+0x18/0x24)
[<c0028be4>] (__bug+0x18/0x24) from [<c01963bc>]
(mmc_omap_start_request+0x358/0x38c)
[<c01963bc>] (mmc_omap_start_request+0x358/0x38c) from [<c018e948>]
(mmc_request_done+0x6c/0xa8)
[<c018e948>] (mmc_request_done+0x6c/0xa8) from [<c0196e38>]
(mmc_omap_irq+0x2f4/0x3b0)
[<c0196e38>] (mmc_omap_irq+0x2f4/0x3b0) from [<c0063efc>]
(handle_IRQ_event+0x24/0xec)
[<c0064efc>] (handle_IRQ_event+0x24/0xec) from [<c0066054>]
(handle_level_irq+0xdc/0x188)
[<c0066054>] (handle_level_irq+0xdc/0x188) from [<c0025068>]
(asm_do_IRQ+0x68/0x88)
[<c0025068>] (asm_do_IRQ+0x68/0x88) from [<c0025a78>] (__irq_svc+0x38/0xa8)
Exception stack(0xc3c25e08 to 0xc3c25e50)
5e00:                   00000001 fffffff9 c0319ac8 fffffffb 80000013 c3c43800
5e20: 00000002 c3cc25f30 00000002 00000001 00000002 c3c43878 0000001f c3c25e50
5e40: c002f540 c0031370 60000013 ffffffff
[<c0025a78>] (__irq_svc+0x38/0xa8) from [<c0031370>] (clk_disable+0x7c/0xb4)
[<c0031370>] (clk_disable+0x7c/0xb4) from [<c018b45c>] (omap_i2c_idle+0xb8/0xcc)
[<c018b45c>] (omap_i2c_idle+0xb8/0xcc) from [<c018b7e0>]
(omap_i2c_xfer+0x370/0x3a8)
[<c018b7e0>] (omap_i2c_xfer+0x370/0x3a8) from [<c0187fa4>]
(i2c_transfer+0x9c/0xf4)
[<c0187fa4>] (i2c_transfer+0x9c/0xf4) from [<c01883e8>]
(i2c_smbus_xfer+0x3ec/0x52c)
[<c01883e8>] (i2c_smbus_xfer+0x3ec/0x52c) from [<c01887e8>]
(i2c_smbus_read_byte_data+0x34/0x44)
[<c01887e8>] (i2c_smbus_read_byte_data+0x34/0x44) from [<c004c118>]
(worker_thread+0x180/0x244)
[<c004c118>] (worker_thread+0x180/0x244) from [<c004f4cc>] (kthread+0x78/0x80)
[<c004f4cc>] (kthread+0x78/0x80) from [<c00268e4>] (kernel_thread_exit+0x0/0x8)

If I replace BUG_ON with WARN_ON, I can get the whole dmesg output,
which contains much the same information (but also the rest of it).
I've attached that here.

- Cory

[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 13712 bytes --]

Linux version 2.6.34-08342-g4eab418-dirty (darkstar62@runt) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68) ) #13 PREEMPT Wed Jun 2 17:00:17 PDT 2010
CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: HTC Herald
Memory policy: ECC disabled, Data cache writethrough
On node 0 totalpages: 16384
free_area_init_node: node 0, pgdat c0319010, node_mem_map c0330000
  Normal zone: 128 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 16256 pages, LIFO batch:3
OMAP0850
 revision 1 handled as 07xx id: 0000000000000000
SRAM: Mapped pa 0x20000000 to va 0xd8000000 size: 0x100000
Timeout waiting for end of frame -- LCD may not be available
htcherald_map_io done.
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: init=/sbin/init console=tty0 video=omapfb:accel fbcon=rotate:3 gsm-wizard.noreset=1 gsm-wizard.noload=1 android:rotate_ccw 3
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 57576k/57576k available, 7960k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xc4800000 - 0xd8000000   ( 312 MB)
    lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc0025000   ( 116 kB)
      .text : 0xc0025000 - 0xc02e3000   (2808 kB)
      .data : 0xc02fa000 - 0xc0319620   ( 126 kB)
Hierarchical RCU implementation.
	RCU-based detection of stalled CPUs is disabled.
	Verbose stalled-CPUs detection is disabled.
NR_IRQS:432
htcherald_init_irq.
Clocks: ARM_SYSST: 0x1040 DPLL_CTL: 0x2fb3 ARM_CKCTL: 0x6506
Clocking rate (xtal/DPLL1/MPU): 13.0/195.0/0.0 MHz
Total of 96 interrupts in 3 interrupt banks
Console: colour dummy device 80x30
console [tty0] enabled
Calibrating delay loop... 97.07 BogoMIPS (lpj=485376)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
HTC Herald init.
OMAP850 Watchdog seems to be activated, disabling it for now.
USB setup complete.
USB: hmc 4, usb2 alt 0 wires
OMAP DMA hardware version 1
DMA capabilities: 000c0000:00000000:01ff:003f:007f
bio: create slab <bio-0> at 0
i2c_omap i2c_omap.1: bus 1 rev2.2 at 100 kHz
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Switching to clocksource mpu_timer2
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Unpacking initramfs...
Freeing initrd memory: 4120K
Power Management for TI OMAP.
msgmni has been set to 120
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
omapfb: configured for panel lcd_herald
omapfb: LCDC initialized
Console: switching to colour frame buffer device 80x40
omapfb: Framebuffer initialized. Total vram 155648 planes 1
omapfb: Pixclock 5735 kHz hfreq 20.1 kHz vfreq 62.6 Hz
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xfffb0000 (irq = 47) is a ST16654
serial8250.0: ttyS1 at MMIO 0xfffb0800 (irq = 46) is a ST16654
serial8250 serial8250.0: unable to register port at index 2 (IO0 MEM0 IRQ15): -28
loop: module loaded
i2c-htcpld i2c-htcpld: Registered chip at 0x3
i2c-htcpld i2c-htcpld: Registered chip at 0x4
i2c-htcpld i2c-htcpld: Registered chip at 0x5
i2c-htcpld i2c-htcpld: Registered chip at 0x6
i2c-htcpld i2c-htcpld: Initialized successfully
udc: OMAP UDC driver, version: 4 October 2004 (iso)
udc: OMAP UDC rev 3.6
udc: hmc mode 4, integrated transceiver
udc: fifo mode 3, 648 bytes not used
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC 5e:8d:55:2a:95:74
usb0: HOST MAC 3a:e2:88:39:ef:2b
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
mice: PS/2 mouse device common for all mice
input: gpio-keys as /devices/platform/gpio-keys/input/input0
OMAP Keypad Driver
input: omap-keypad as /devices/platform/omap-keypad/input/input1
ads7846 spi2.1: touchscreen, irq 236
input: ADS7846 Touchscreen as /devices/platform/omap1_spi100k.2/spi2.1/input/input2
i2c /dev entries driver
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCILL protocol initialized
Registered led device: dpad
Registered led device: kbd
Registered led device: vibrate
Registered led device: green_solid
Registered led device: green_flash
Registered led device: red_solid
Registered led device: red_flash
Registered led device: wifi
Registered led device: bt
Registered led device: caps
Registered led device: alt
TCP cubic registered
NET: Registered protocol family 17
mmci-omap mmci-omap.0: command timeout (CMD52)
Bluetooth: L2CAP ver 2.14
mmci-omap mmci-omap.0: command timeout (CMD52)
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
udc: USB reset done, gadget g_ether
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
mmci-omap mmci-omap.0: command timeout (CMD5)
------------[ cut here ]------------
WARNING: at drivers/mmc/host/omap.c:1160 mmc_omap_start_request+0x354/0x388()
Modules linked in:
[<c002a280>] (unwind_backtrace+0x0/0xec) from [<c0039d94>] (warn_slowpath_common+0x48/0x60)
[<c0039d94>] (warn_slowpath_common+0x48/0x60) from [<c0039dc4>] (warn_slowpath_null+0x18/0x1c)
[<c0039dc4>] (warn_slowpath_null+0x18/0x1c) from [<c01963b8>] (mmc_omap_start_request+0x354/0x388)
[<c01963b8>] (mmc_omap_start_request+0x354/0x388) from [<c018e948>] (mmc_request_done+0x6c/0xa8)
[<c018e948>] (mmc_request_done+0x6c/0xa8) from [<c0196e34>] (mmc_omap_irq+0x2f4/0x3b0)
[<c0196e34>] (mmc_omap_irq+0x2f4/0x3b0) from [<c0063efc>] (handle_IRQ_event+0x24/0xec)
[<c0063efc>] (handle_IRQ_event+0x24/0xec) from [<c0066054>] (handle_level_irq+0xdc/0x188)
[<c0066054>] (handle_level_irq+0xdc/0x188) from [<c0025068>] (asm_do_IRQ+0x68/0x88)
[<c0025068>] (asm_do_IRQ+0x68/0x88) from [<c0025a78>] (__irq_svc+0x38/0xa8)
Exception stack(0xc3c25e08 to 0xc3c25e50)
5e00:                   00000001 fffffff9 c0319ac8 fffffffb 80000013 c3c2d800
5e20: 00000002 c3c25f30 00000002 00000001 00000002 c3c2d878 0000001f c3c25e50
5e40: c002f540 c0031370 60000013 ffffffff
[<c0025a78>] (__irq_svc+0x38/0xa8) from [<c0031370>] (clk_disable+0x7c/0xb4)
[<c0031370>] (clk_disable+0x7c/0xb4) from [<c018b45c>] (omap_i2c_idle+0xb8/0xcc)
[<c018b45c>] (omap_i2c_idle+0xb8/0xcc) from [<c018b7e0>] (omap_i2c_xfer+0x370/0x3a8)
[<c018b7e0>] (omap_i2c_xfer+0x370/0x3a8) from [<c0187fa4>] (i2c_transfer+0x9c/0xf4)
[<c0187fa4>] (i2c_transfer+0x9c/0xf4) from [<c01883e8>] (i2c_smbus_xfer+0x3ec/0x52c)
[<c01883e8>] (i2c_smbus_xfer+0x3ec/0x52c) from [<c01887e8>] (i2c_smbus_read_byte_data+0x34/0x44)
[<c01887e8>] (i2c_smbus_read_byte_data+0x34/0x44) from [<c004c118>] (worker_thread+0x180/0x244)
[<c004c118>] (worker_thread+0x180/0x244) from [<c004f4cc>] (kthread+0x78/0x80)
[<c004f4cc>] (kthread+0x78/0x80) from [<c00268e4>] (kernel_thread_exit+0x0/0x8)
---[ end trace 7a5aada48eab534b ]---
mmci-omap mmci-omap.0: command timeout (CMD5)
------------[ cut here ]------------
WARNING: at drivers/mmc/host/omap.c:1160 mmc_omap_start_request+0x354/0x388()
Modules linked in:
[<c002a280>] (unwind_backtrace+0x0/0xec) from [<c0039d94>] (warn_slowpath_common+0x48/0x60)
[<c0039d94>] (warn_slowpath_common+0x48/0x60) from [<c0039dc4>] (warn_slowpath_null+0x18/0x1c)
[<c0039dc4>] (warn_slowpath_null+0x18/0x1c) from [<c01963b8>] (mmc_omap_start_request+0x354/0x388)
[<c01963b8>] (mmc_omap_start_request+0x354/0x388) from [<c018e948>] (mmc_request_done+0x6c/0xa8)
[<c018e948>] (mmc_request_done+0x6c/0xa8) from [<c0196e34>] (mmc_omap_irq+0x2f4/0x3b0)
[<c0196e34>] (mmc_omap_irq+0x2f4/0x3b0) from [<c0063efc>] (handle_IRQ_event+0x24/0xec)
[<c0063efc>] (handle_IRQ_event+0x24/0xec) from [<c0066054>] (handle_level_irq+0xdc/0x188)
[<c0066054>] (handle_level_irq+0xdc/0x188) from [<c0025068>] (asm_do_IRQ+0x68/0x88)
[<c0025068>] (asm_do_IRQ+0x68/0x88) from [<c0025a78>] (__irq_svc+0x38/0xa8)
Exception stack(0xc3c25d80 to 0xc3c25dc8)
5d80: 3801fe31 00000000 00000003 20000013 c3c24000 00000202 00000000 00000002
5da0: 0000000a c3c24000 00000002 c3c2d878 c3c15350 c3c25dc8 c003f33c c003f234
5dc0: 20000013 ffffffff
[<c0025a78>] (__irq_svc+0x38/0xa8) from [<c003f234>] (__do_softirq+0x40/0x108)
[<c003f234>] (__do_softirq+0x40/0x108) from [<c003f33c>] (irq_exit+0x40/0x60)
[<c003f33c>] (irq_exit+0x40/0x60) from [<c002506c>] (asm_do_IRQ+0x6c/0x88)
[<c002506c>] (asm_do_IRQ+0x6c/0x88) from [<c0025a78>] (__irq_svc+0x38/0xa8)
Exception stack(0xc3c25e08 to 0xc3c25e50)
5e00:                   00000001 fffffff9 c0319ac8 fffffffb 80000013 c3c2d800
5e20: 00000002 c3c25f30 00000002 00000001 00000002 c3c2d878 0000001f c3c25e50
5e40: c002f540 c0031370 60000013 ffffffff
[<c0025a78>] (__irq_svc+0x38/0xa8) from [<c0031370>] (clk_disable+0x7c/0xb4)
[<c0031370>] (clk_disable+0x7c/0xb4) from [<c018b45c>] (omap_i2c_idle+0xb8/0xcc)
[<c018b45c>] (omap_i2c_idle+0xb8/0xcc) from [<c018b7e0>] (omap_i2c_xfer+0x370/0x3a8)
[<c018b7e0>] (omap_i2c_xfer+0x370/0x3a8) from [<c0187fa4>] (i2c_transfer+0x9c/0xf4)
[<c0187fa4>] (i2c_transfer+0x9c/0xf4) from [<c01883e8>] (i2c_smbus_xfer+0x3ec/0x52c)
[<c01883e8>] (i2c_smbus_xfer+0x3ec/0x52c) from [<c01887e8>] (i2c_smbus_read_byte_data+0x34/0x44)
[<c01887e8>] (i2c_smbus_read_byte_data+0x34/0x44) from [<c004c118>] (worker_thread+0x180/0x244)
[<c004c118>] (worker_thread+0x180/0x244) from [<c004f4cc>] (kthread+0x78/0x80)
[<c004f4cc>] (kthread+0x78/0x80) from [<c00268e4>] (kernel_thread_exit+0x0/0x8)
---[ end trace 7a5aada48eab534c ]---
mmci-omap mmci-omap.0: command timeout (CMD5)
------------[ cut here ]------------
WARNING: at drivers/mmc/host/omap.c:1160 mmc_omap_start_request+0x354/0x388()
Modules linked in:
[<c002a280>] (unwind_backtrace+0x0/0xec) from [<c0039d94>] (warn_slowpath_common+0x48/0x60)
[<c0039d94>] (warn_slowpath_common+0x48/0x60) from [<c0039dc4>] (warn_slowpath_null+0x18/0x1c)
[<c0039dc4>] (warn_slowpath_null+0x18/0x1c) from [<c01963b8>] (mmc_omap_start_request+0x354/0x388)
[<c01963b8>] (mmc_omap_start_request+0x354/0x388) from [<c018e948>] (mmc_request_done+0x6c/0xa8)
[<c018e948>] (mmc_request_done+0x6c/0xa8) from [<c0196e34>] (mmc_omap_irq+0x2f4/0x3b0)
[<c0196e34>] (mmc_omap_irq+0x2f4/0x3b0) from [<c0063efc>] (handle_IRQ_event+0x24/0xec)
[<c0063efc>] (handle_IRQ_event+0x24/0xec) from [<c0066054>] (handle_level_irq+0xdc/0x188)
[<c0066054>] (handle_level_irq+0xdc/0x188) from [<c0025068>] (asm_do_IRQ+0x68/0x88)
[<c0025068>] (asm_do_IRQ+0x68/0x88) from [<c0025a78>] (__irq_svc+0x38/0xa8)
Exception stack(0xc3c25d80 to 0xc3c25dc8)
5d80: 3801fe31 00000000 00000003 20000013 c3c24000 00000202 00000000 00000002
5da0: 0000000a c3c24000 00000002 c3c2d878 c3c15350 c3c25dc8 c003f33c c003f234
5dc0: 20000013 ffffffff
[<c0025a78>] (__irq_svc+0x38/0xa8) from [<c003f234>] (__do_softirq+0x40/0x108)
[<c003f234>] (__do_softirq+0x40/0x108) from [<c003f33c>] (irq_exit+0x40/0x60)
[<c003f33c>] (irq_exit+0x40/0x60) from [<c002506c>] (asm_do_IRQ+0x6c/0x88)
[<c002506c>] (asm_do_IRQ+0x6c/0x88) from [<c0025a78>] (__irq_svc+0x38/0xa8)
Exception stack(0xc3c25e08 to 0xc3c25e50)
5e00:                   00000001 fffffff9 c0319ac8 fffffffb 80000013 c3c2d800
5e20: 00000002 c3c25f30 00000002 00000001 00000002 c3c2d878 0000001f c3c25e50
5e40: c002f540 c0031370 60000013 ffffffff
[<c0025a78>] (__irq_svc+0x38/0xa8) from [<c0031370>] (clk_disable+0x7c/0xb4)
[<c0031370>] (clk_disable+0x7c/0xb4) from [<c018b45c>] (omap_i2c_idle+0xb8/0xcc)
[<c018b45c>] (omap_i2c_idle+0xb8/0xcc) from [<c018b7e0>] (omap_i2c_xfer+0x370/0x3a8)
[<c018b7e0>] (omap_i2c_xfer+0x370/0x3a8) from [<c0187fa4>] (i2c_transfer+0x9c/0xf4)
[<c0187fa4>] (i2c_transfer+0x9c/0xf4) from [<c01883e8>] (i2c_smbus_xfer+0x3ec/0x52c)
[<c01883e8>] (i2c_smbus_xfer+0x3ec/0x52c) from [<c01887e8>] (i2c_smbus_read_byte_data+0x34/0x44)
[<c01887e8>] (i2c_smbus_read_byte_data+0x34/0x44) from [<c004c118>] (worker_thread+0x180/0x244)
[<c004c118>] (worker_thread+0x180/0x244) from [<c004f4cc>] (kthread+0x78/0x80)
[<c004f4cc>] (kthread+0x78/0x80) from [<c00268e4>] (kernel_thread_exit+0x0/0x8)
---[ end trace 7a5aada48eab534d ]---
mmci-omap mmci-omap.0: command timeout (CMD5)
MUX: initialized UART_7XX_1
MUX: initialized UART_7XX_2
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SDHC card at address ede2
mmcblk0: mmc0:ede2 SU16G 14.8 GiB 
 mmcblk0: p1
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Freeing init memory: 116K
EXT2-fs (loop0): warning: maximal mount count reached, running e2fsck is recommended
udc: USB reset done, gadget g_ether
udc: USB reset done, gadget g_ether
g_ether gadget: full speed config #1: CDC Ethernet (ECM)