irqdomain breaks ap4 boot

irqdomain breaks ap4 boot

[kuninori.morimoto.gx]

Hi Paul

I noticed that sh irqdomain commit breaks mackerel boot.
below is "git bisect" result and kernel log

------- log -----------------------------
...
NR_IRQS:16 nr_irqs:16 16
intc: Registered controller 'sh7372-intca' with 108 IRQs
intc: Registered controller 'sh7372-intca-irq-lo' with 16 IRQs
intc: can't get irq_desc for 0
intc: can't get irq_desc for 1
intc: can't get irq_desc for 2
intc: can't get irq_desc for 3
intc: can't get irq_desc for 4
intc: can't get irq_desc for 5
intc: can't get irq_desc for 6
intc: can't get irq_desc for 7
intc: can't get irq_desc for 8
intc: can't get irq_desc for 9
intc: can't get irq_desc for 10
intc: can't get irq_desc for 11
intc: can't get irq_desc for 12
intc: can't get irq_desc for 13
intc: can't get irq_desc for 14
intc: can't get irq_desc for 15
intc: Registered controller 'sh7372-intca-irq-hi' with 16 IRQs
kmemleak: Kernel memory leak detector disabled
intc: Registered controller 'sh7372-intcs' with 61 IRQs
(snip)
tca6416-keypad: probe of 0-0020 failed with error -22
(snip)
smsc911x: probe of smsc911x failed with error -22
(snip)
renesas_usbhs: probe of renesas_usbhs.1 failed with error -22
(snip)
asoc-simple-card asoc-simple-card.1:  sh_mobile_hdmi-hifi <-> fsib-dai mapping k
ALSA device list:
  #0: FSI2A-AK4643
  #1: FSI2B-HDMI
Root-NFS: no NFS server address
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
[<c000d1c8>] (unwind_backtrace+0x0/0xe0) from [<c029fa10>] (panic+0x84/0x1e4)
[<c029fa10>] (panic+0x84/0x1e4) from [<c03b0c20>] (mount_block_root+0x1d4/0x218)
[<c03b0c20>] (mount_block_root+0x1d4/0x218) from [<c03b0d50>] (mount_root+0xec/)
[<c03b0d50>] (mount_root+0xec/0x10c) from [<c03b0e88>] (prepare_namespace+0x118)
[<c03b0e88>] (prepare_namespace+0x118/0x16c) from [<c03b0888>] (kernel_init+0x1)
[<c03b0888>] (kernel_init+0x168/0x1a4) from [<c0009888>] (kernel_thread_exit+0x)

---------- commit -----------------------
1d6a21b0a672fb29b01ccf397d478e0541e17716 is the first bad commit
commit 1d6a21b0a672fb29b01ccf397d478e0541e17716
Author: Paul Mundt <lethal@linux-sh.org>
Date:   Wed Aug 1 17:13:46 2012 +0900

sh: intc: initial irqdomain support.

Trivial support for irq domains, using either a linear map or radix tree
depending on the vector layout.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

:040000 040000 2997b842c38d729a1a90842a4e6175844c4e4c2e fce82bc1fb83a3cd9ddd324c7baba897a3f131dc M	drivers
--------------------------------------------

Re: irqdomain breaks ap4 boot

[Paul Mundt]

On Thu, Aug 02, 2012 at 02:50:26AM -0700, kuninori.morimoto.gx@renesas.com wrote:
> 
> Hi Paul
> 
> I noticed that sh irqdomain commit breaks mackerel boot.
> below is "git bisect" result and kernel log
> 
> ------- log -----------------------------
> ...
> NR_IRQS:16 nr_irqs:16 16
> intc: Registered controller 'sh7372-intca' with 108 IRQs
> intc: Registered controller 'sh7372-intca-irq-lo' with 16 IRQs
> intc: can't get irq_desc for 0
> intc: can't get irq_desc for 1
> intc: can't get irq_desc for 2
> intc: can't get irq_desc for 3
> intc: can't get irq_desc for 4
> intc: can't get irq_desc for 5
> intc: can't get irq_desc for 6
> intc: can't get irq_desc for 7
> intc: can't get irq_desc for 8
> intc: can't get irq_desc for 9
> intc: can't get irq_desc for 10
> intc: can't get irq_desc for 11
> intc: can't get irq_desc for 12
> intc: can't get irq_desc for 13
> intc: can't get irq_desc for 14
> intc: can't get irq_desc for 15
> intc: Registered controller 'sh7372-intca-irq-hi' with 16 IRQs

Great, it's ARM's silly NR_IRQS_LEGACY getting in the way, and we don't
seem to have any ability to simply not pre-allocate IRQs given that ARM's
machine_desc lamely doesn't allow 0 as a valid nr_irqs initializer even
on sparseirq configurations.

It's not entirely obvious why you are tripping up on this though, as we
should already gracefully handle the -EEXIST case.

I'll have a bit of a think over how to fix it properly.

Re: irqdomain breaks ap4 boot

[Paul Mundt]

On Fri, Aug 03, 2012 at 02:00:40PM +0900, Paul Mundt wrote:
> On Thu, Aug 02, 2012 at 02:50:26AM -0700, kuninori.morimoto.gx@renesas.com wrote:
> > 
> > Hi Paul
> > 
> > I noticed that sh irqdomain commit breaks mackerel boot.
> > below is "git bisect" result and kernel log
> > 
> > ------- log -----------------------------
> > ...
> > NR_IRQS:16 nr_irqs:16 16
> > intc: Registered controller 'sh7372-intca' with 108 IRQs
> > intc: Registered controller 'sh7372-intca-irq-lo' with 16 IRQs
> > intc: can't get irq_desc for 0
> > intc: can't get irq_desc for 1
> > intc: can't get irq_desc for 2
> > intc: can't get irq_desc for 3
> > intc: can't get irq_desc for 4
> > intc: can't get irq_desc for 5
> > intc: can't get irq_desc for 6
> > intc: can't get irq_desc for 7
> > intc: can't get irq_desc for 8
> > intc: can't get irq_desc for 9
> > intc: can't get irq_desc for 10
> > intc: can't get irq_desc for 11
> > intc: can't get irq_desc for 12
> > intc: can't get irq_desc for 13
> > intc: can't get irq_desc for 14
> > intc: can't get irq_desc for 15
> > intc: Registered controller 'sh7372-intca-irq-hi' with 16 IRQs
> 
> Great, it's ARM's silly NR_IRQS_LEGACY getting in the way, and we don't
> seem to have any ability to simply not pre-allocate IRQs given that ARM's
> machine_desc lamely doesn't allow 0 as a valid nr_irqs initializer even
> on sparseirq configurations.
> 
> It's not entirely obvious why you are tripping up on this though, as we
> should already gracefully handle the -EEXIST case.
> 
> I'll have a bit of a think over how to fix it properly.

Ok, it's fixed now. We were previously handling the -EEXIST case but were
getting tripped up by moving the irq_desc allocation in to the irq domain
code and not handling the failure case for pre-allocated vectors with
sparseirq.

I'll send this off for -rc2:

---

commit 1026023705b0baa2b37df2a0d1da0022fc7b985e
Author: Paul Mundt <lethal@linux-sh.org>
Date:   Thu Aug 9 12:59:40 2012 +0900

    sh: intc: Handle domain association for sparseirq pre-allocated vectors.
    
    Presently it's assumed that the irqdomain code handles the irq_desc
    allocation for us, but this isn't necessarily the case when we've
    pre-allocated IRQs via sparseirq. Previously we had a -EEXIST check in
    the code that attempted to trap these cases and simply update them
    in-place, but this behaviour was inadvertently lost in the transition to
    irqdomains.
    
    This simply restores the previous behaviour, first attempting to let the
    irqdomain core fetch the allocation for us, and falling back to an
    in-place domain association in the extant IRQ case. Fixes up regressions
    on platforms that pre-allocate legacy IRQs (specifically ARM-based
    SH-Mobile platforms, as SH stopped pre-allocating vectors some time ago).
    
    Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Paul Mundt <lethal@linux-sh.org>

diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
index 2374468..32c26d7 100644
--- a/drivers/sh/intc/core.c
+++ b/drivers/sh/intc/core.c
@@ -324,8 +324,16 @@ int __init register_intc_controller(struct intc_desc *desc)
 
 		res = irq_create_identity_mapping(d->domain, irq);
 		if (unlikely(res)) {
-			pr_err("can't get irq_desc for %d\n", irq);
-			continue;
+			if (res = -EEXIST) {
+				res = irq_domain_associate(d->domain, irq, irq);
+				if (unlikely(res)) {
+					pr_err("domain association failure\n");
+					continue;
+				}
+			} else {
+				pr_err("can't identity map IRQ %d\n", irq);
+				continue;
+			}
 		}
 
 		intc_irq_xlate_set(irq, vect->enum_id, d);
@@ -345,8 +353,19 @@ int __init register_intc_controller(struct intc_desc *desc)
 			 */
 			res = irq_create_identity_mapping(d->domain, irq2);
 			if (unlikely(res)) {
-				pr_err("can't get irq_desc for %d\n", irq2);
-				continue;
+				if (res = -EEXIST) {
+					res = irq_domain_associate(d->domain,
+								   irq, irq);
+					if (unlikely(res)) {
+						pr_err("domain association "
+						       "failure\n");
+						continue;
+					}
+				} else {
+					pr_err("can't identity map IRQ %d\n",
+					       irq);
+					continue;
+				}
 			}
 
 			vect2->enum_id = 0;

Re: irqdomain breaks ap4 boot

[Kuninori Morimoto]

Hi Paul

Thank you for your hard work

> commit 1026023705b0baa2b37df2a0d1da0022fc7b985e
> Author: Paul Mundt <lethal@linux-sh.org>
> Date:   Thu Aug 9 12:59:40 2012 +0900
> 
>     sh: intc: Handle domain association for sparseirq pre-allocated vectors.
>     
>     Presently it's assumed that the irqdomain code handles the irq_desc
>     allocation for us, but this isn't necessarily the case when we've
>     pre-allocated IRQs via sparseirq. Previously we had a -EEXIST check in
>     the code that attempted to trap these cases and simply update them
>     in-place, but this behaviour was inadvertently lost in the transition to
>     irqdomains.
>     
>     This simply restores the previous behaviour, first attempting to let the
>     irqdomain core fetch the allocation for us, and falling back to an
>     in-place domain association in the extant IRQ case. Fixes up regressions
>     on platforms that pre-allocate legacy IRQs (specifically ARM-based
>     SH-Mobile platforms, as SH stopped pre-allocating vectors some time ago).
>     
>     Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>     Signed-off-by: Paul Mundt <lethal@linux-sh.org>

This patch solved mackerel board crush bug on linus/master


Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Best regards
---
Kuninori Morimoto

Re: irqdomain breaks ap4 boot

[Kuninori Morimoto]

Hi Paul

> >     sh: intc: Handle domain association for sparseirq pre-allocated vectors.
> >     
> >     Presently it's assumed that the irqdomain code handles the irq_desc
> >     allocation for us, but this isn't necessarily the case when we've
> >     pre-allocated IRQs via sparseirq. Previously we had a -EEXIST check in
> >     the code that attempted to trap these cases and simply update them
> >     in-place, but this behaviour was inadvertently lost in the transition to
> >     irqdomains.
> >     
> >     This simply restores the previous behaviour, first attempting to let the
> >     irqdomain core fetch the allocation for us, and falling back to an
> >     in-place domain association in the extant IRQ case. Fixes up regressions
> >     on platforms that pre-allocate legacy IRQs (specifically ARM-based
> >     SH-Mobile platforms, as SH stopped pre-allocating vectors some time ago).
> >     
> >     Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >     Signed-off-by: Paul Mundt <lethal@linux-sh.org>
> 
> This patch solved mackerel board crush bug on linus/master

ecovec/armadillo/marzen board were OK on this patch,
but kzm9g board still has problem.
I'm using "linus/master + paul/sh-latest"

========= kernel log ==============-
....
Preemptible hierarchical RCU implementation.                                    
        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.                    
NR_IRQS:16 nr_irqs:16 16                                                        
intc: Registered controller 'sh73a0-intcs' with 77 IRQs                         
intc: Registered controller 'sh73a0-intca-irq-pins' with 32 IRQs                
------------[ cut here ]------------                                            
WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
error: irq_desc already associated; irqU2 hwirq=0x228                         
Modules linked in:                                                              
Backtrace:                                                                      
[<c0012358>] (dump_backtrace+0x0/0x10c) from [<c02e7e1c>] (dump_stack+0x18/0x1c)
 r6:c00655ec r5:00000009 r4:c03e9ed8 r3:c0404908                                
[<c02e7e04>] (dump_stack+0x0/0x1c) from [<c001cecc>] (warn_slowpath_common+0x54)
[<c001ce78>] (warn_slowpath_common+0x0/0x6c) from [<c001cf88>] (warn_slowpath_f)
 r8:00000228 r7:c03de574 r6:00000228 r5:00000000 r4:de8029c0                    
r3:00000009                                                                     
[<c001cf50>] (warn_slowpath_fmt+0x0/0x40) from [<c00655ec>] (irq_domain_associa)
 r3:00000228 r2:c037fb49                                                        
[<c006557c>] (irq_domain_associate_many+0x0/0x1b8) from [<c03d48a4>] (register_)
[<c03d4360>] (register_intc_controller+0x0/0x984) from [<c03c6e68>] (sh73a0_ini)
[<c03c6e04>] (sh73a0_init_irq+0x0/0x1c0) from [<c03c261c>] (init_IRQ+0x1c/0x24) 
 r7:c08a90c0 r6:c03dd774 r5:c03e8000 r4:c041ba80                                
[<c03c2600>] (init_IRQ+0x0/0x24) from [<c03c1744>] (start_kernel+0x19c/0x2a0)   
[<c03c15a8>] (start_kernel+0x0/0x2a0) from [<41008040>] (0x41008040)            
 r7:c03f3b4c r6:c03dd770 r5:c03f047c r4:10c5387d                                
---[ end trace 1b75b31a2719ed1c ]---                                            
intc: domain association failure                        

Best regards
---
Kuninori Morimoto

Re: irqdomain breaks ap4 boot

[Paul Mundt]

On Thu, Aug 09, 2012 at 11:10:43PM -0700, Kuninori Morimoto wrote:
> 
> Hi Paul
> 
> > >     sh: intc: Handle domain association for sparseirq pre-allocated vectors.
> > >     
> > >     Presently it's assumed that the irqdomain code handles the irq_desc
> > >     allocation for us, but this isn't necessarily the case when we've
> > >     pre-allocated IRQs via sparseirq. Previously we had a -EEXIST check in
> > >     the code that attempted to trap these cases and simply update them
> > >     in-place, but this behaviour was inadvertently lost in the transition to
> > >     irqdomains.
> > >     
> > >     This simply restores the previous behaviour, first attempting to let the
> > >     irqdomain core fetch the allocation for us, and falling back to an
> > >     in-place domain association in the extant IRQ case. Fixes up regressions
> > >     on platforms that pre-allocate legacy IRQs (specifically ARM-based
> > >     SH-Mobile platforms, as SH stopped pre-allocating vectors some time ago).
> > >     
> > >     Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > >     Signed-off-by: Paul Mundt <lethal@linux-sh.org>
> > 
> > This patch solved mackerel board crush bug on linus/master
> 
> ecovec/armadillo/marzen board were OK on this patch,
> but kzm9g board still has problem.
> I'm using "linus/master + paul/sh-latest"
> 
> ========= kernel log ==============-
> ....
> Preemptible hierarchical RCU implementation.                                    
>         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.                    
> NR_IRQS:16 nr_irqs:16 16                                                        
> intc: Registered controller 'sh73a0-intcs' with 77 IRQs                         
> intc: Registered controller 'sh73a0-intca-irq-pins' with 32 IRQs                
> ------------[ cut here ]------------                                            
> WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
> error: irq_desc already associated; irqU2 hwirq=0x228                         

I screwed up the multi-evt case, it should be trying to associate irq2,
not irq. Try this:

---

diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
index 32c26d7..8f32a13 100644
--- a/drivers/sh/intc/core.c
+++ b/drivers/sh/intc/core.c
@@ -355,7 +355,7 @@ int __init register_intc_controller(struct intc_desc *desc)
 			if (unlikely(res)) {
 				if (res = -EEXIST) {
 					res = irq_domain_associate(d->domain,
-								   irq, irq);
+								   irq2, irq2);
 					if (unlikely(res)) {
 						pr_err("domain association "
 						       "failure\n");

kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Tetsuyuki Kobayashi]

Hello, Paul

I tried kzm9g board on v3.6-rc2 and got the same error as Morimoto's.

(2012/08/10 21:38), Paul Mundt wrote:
> On Thu, Aug 09, 2012 at 11:10:43PM -0700, Kuninori Morimoto wrote:

>> ecovec/armadillo/marzen board were OK on this patch,
>> but kzm9g board still has problem.
>> I'm using "linus/master + paul/sh-latest"
>>
>> ========= kernel log ==============-
>> ....
>> Preemptible hierarchical RCU implementation.
>>          RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
>> NR_IRQS:16 nr_irqs:16 16
>> intc: Registered controller 'sh73a0-intcs' with 77 IRQs
>> intc: Registered controller 'sh73a0-intca-irq-pins' with 32 IRQs
>> ------------[ cut here ]------------
>> WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
>> error: irq_desc already associated; irqU2 hwirq=0x228
>
> I screwed up the multi-evt case, it should be trying to associate irq2,
> not irq. Try this:
>
> ---
>
> diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
> index 32c26d7..8f32a13 100644
> --- a/drivers/sh/intc/core.c
> +++ b/drivers/sh/intc/core.c
> @@ -355,7 +355,7 @@ int __init register_intc_controller(struct intc_desc *desc)
>   			if (unlikely(res)) {
>   				if (res = -EEXIST) {
>   					res = irq_domain_associate(d->domain,
> -								   irq, irq);
> +								   irq2, irq2);
>   					if (unlikely(res)) {
>   						pr_err("domain association "
>   						       "failure\n");

I tried this patch but there is still the same error.
I checked quickly by debugger, and I found the failing 
irq_domain_associate() is not called here (line 357) but the one at line 
328.

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Kuninori Morimoto]

Hi Paul

Thank you for your patch

> > diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
> > index 32c26d7..8f32a13 100644
> > --- a/drivers/sh/intc/core.c
> > +++ b/drivers/sh/intc/core.c
> > @@ -355,7 +355,7 @@ int __init register_intc_controller(struct intc_desc *desc)
> >   			if (unlikely(res)) {
> >   				if (res = -EEXIST) {
> >   					res = irq_domain_associate(d->domain,
> > -								   irq, irq);
> > +								   irq2, irq2);
> >   					if (unlikely(res)) {
> >   						pr_err("domain association "
> >   						       "failure\n");
> 
> I tried this patch but there is still the same error.
> I checked quickly by debugger, and I found the failing 
> irq_domain_associate() is not called here (line 357) but the one at line 
> 328.

But, I got same result.

This WARNING is indicating
> intc: domain association failure    
      
So, as kobayashi-san said, 
it has happend on previous irq_domain_associate(), not here.

Best regards
---
Kuninori Morimoto

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Paul Mundt]

On Sun, Aug 19, 2012 at 06:14:41PM -0700, Kuninori Morimoto wrote:
> 
> Hi Paul
> 
> Thank you for your patch
> 
> > > diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
> > > index 32c26d7..8f32a13 100644
> > > --- a/drivers/sh/intc/core.c
> > > +++ b/drivers/sh/intc/core.c
> > > @@ -355,7 +355,7 @@ int __init register_intc_controller(struct intc_desc *desc)
> > >   			if (unlikely(res)) {
> > >   				if (res = -EEXIST) {
> > >   					res = irq_domain_associate(d->domain,
> > > -								   irq, irq);
> > > +								   irq2, irq2);
> > >   					if (unlikely(res)) {
> > >   						pr_err("domain association "
> > >   						       "failure\n");
> > 
> > I tried this patch but there is still the same error.
> > I checked quickly by debugger, and I found the failing 
> > irq_domain_associate() is not called here (line 357) but the one at line 
> > 328.
> 
> But, I got same result.
> 
> This WARNING is indicating
> > intc: domain association failure    
>       
> So, as kobayashi-san said, 
> it has happend on previous irq_domain_associate(), not here.
> 
Can you post a boot log with the pr_debug() output in the irqdomain code
enabled? You may need to add ignore_loglevel to your kernel command line.

If that doesn't produce any further clues I'll have to find one of these
boards to see what's going on.

---

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 49a7772..3b39c0e 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1,5 +1,7 @@
 #define pr_fmt(fmt)  "irq: " fmt
 
+#define DEBUG
+
 #include <linux/debugfs.h>
 #include <linux/hardirq.h>
 #include <linux/interrupt.h>

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Kuninori Morimoto]

Hi Paul

> Can you post a boot log with the pr_debug() output in the irqdomain code
> enabled? You may need to add ignore_loglevel to your kernel command line.
> 
> If that doesn't produce any further clues I'll have to find one of these
> boards to see what's going on.

This is my log

---------------------------
Starting kernel ...                                                             
                                                                                
Booting Linux on physical CPU 0                                                 
Linux version 3.6.0-rc1+ (morimoto@morimoto-Dell-XPS420) (gcc version 4.7.1 2012
CPU: ARMv7 Processor [412fc098] revision 8 (ARMv7), cr\x10c5387d                 
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache        
Machine: kzm9g                                                                  
Memory policy: ECC disabled, Data cache writealloc                              
PERCPU: Embedded 7 pages/cpu @c08ac000 s6592 r8192 d13888 u32768                
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 125860     
Kernel command line: root=/dev/null console=ttySC4,115200                       
PID hash table entries: 2048 (order: 1, 8192 bytes)                             
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)                 
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)                  
Memory: 496MB = 496MB total                                                     
Memory: 498600k/498600k available, 9304k reserved, 0K highmem                   
Virtual kernel memory layout:                                                   
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)                               
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)                               
    vmalloc : 0xdf800000 - 0xff000000   ( 504 MB)                               
    lowmem  : 0xc0000000 - 0xdf000000   ( 496 MB)                               
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)                               
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)                               
      .text : 0xc0008000 - 0xc03c1000   (3812 kB)                               
      .init : 0xc03c1000 - 0xc03e79c0   ( 155 kB)                               
      .data : 0xc03e8000 - 0xc041ba40   ( 207 kB)                               
       .bss : 0xc041ba64 - 0xc044a044   ( 186 kB)                               
Preemptible hierarchical RCU implementation.                                    
        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.                    
NR_IRQS:16 nr_irqs:16 16                                                        
irq: Allocated domain of type 0 @0xde802800                                     
intc: Registered controller 'sh73a0-intcs' with 77 IRQs                         
irq: Allocated domain of type 3 @0xde802940                                     
irq: irq_domain_associate_many(<no-node>, irqbaseD8, hwbaseD8, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseD9, hwbaseD9, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseF4, hwbaseF4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseF5, hwbaseF5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseF6, hwbaseF6, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseF7, hwbaseF7, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseF8, hwbaseF8, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseG2, hwbaseG2, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseG5, hwbaseG5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseG6, hwbaseG6, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseG7, hwbaseG7, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseG9, hwbaseG9, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseH0, hwbaseH0, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseI2, hwbaseI2, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseI3, hwbaseI3, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseI4, hwbaseI4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseI5, hwbaseI5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseP0, hwbaseP0, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseP5, hwbaseP5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseQ6, hwbaseQ6, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseQ7, hwbaseQ7, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseQ8, hwbaseQ8, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseR0, hwbaseR0, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseR1, hwbaseR1, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseR2, hwbaseR2, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseR3, hwbaseR3, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseR4, hwbaseR4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseR5, hwbaseR5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseR6, hwbaseR6, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseC2, hwbaseC2, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseC4, hwbaseC4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseC6, hwbaseC6, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseC7, hwbaseC7, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseC8, hwbaseC8, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseD3, hwbaseD3, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseD4, hwbaseD4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseD5, hwbaseD5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseU3, hwbaseU3, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseU4, hwbaseU4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseU5, hwbaseU5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseU6, hwbaseU6, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseU7, hwbaseU7, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseX4, hwbaseX4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseX7, hwbaseX7, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseX8, hwbaseX8, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseX9, hwbaseX9, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseY0, hwbaseY0, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseY1, hwbaseY1, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseY2, hwbaseY2, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseY3, hwbaseY3, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseY4, hwbaseY4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbase`0, hwbase`0, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbase`1, hwbase`1, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbase`2, hwbase`2, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbase`3, hwbase`3, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbase`4, hwbase`4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbase`8, hwbase`8, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbase`9, hwbase`9, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbasea5, hwbasea5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbasea6, hwbasea6, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbasea8, hwbasea8, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbasea9, hwbasea9, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseb0, hwbaseb0, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseb1, hwbaseb1, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseb3, hwbaseb3, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseb4, hwbaseb4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseb5, hwbaseb5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseb6, hwbaseb6, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseb7, hwbaseb7, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseb8, hwbaseb8, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseb9, hwbaseb9, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbasec0, hwbasec0, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbasec1, hwbasec1, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbasec2, hwbasec2, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbasec3, hwbasec3, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseh0, hwbaseh0, count=1)     
intc: Registered controller 'sh73a0-intca-irq-pins' with 32 IRQs                
irq: Allocated domain of type 3 @0xde8029c0                                     
irq: irq_domain_associate_many(<no-node>, irqbaseT4, hwbaseT4, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseT5, hwbaseT5, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseT6, hwbaseT6, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseT7, hwbaseT7, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseT8, hwbaseT8, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseT9, hwbaseT9, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseU0, hwbaseU0, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseU1, hwbaseU1, count=1)     
irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)     
------------[ cut here ]------------                                            
WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
error: irq_desc already associated; irqU2 hwirq=0x228                         
Modules linked in:                                                              
Backtrace:                                                                      
[<c0012358>] (dump_backtrace+0x0/0x10c) from [<c02e7e1c>] (dump_stack+0x18/0x1c)
 r6:c0065640 r5:00000009 r4:c03e9ed8 r3:c0404908                                
[<c02e7e04>] (dump_stack+0x0/0x1c) from [<c001cecc>] (warn_slowpath_common+0x54)
[<c001ce78>] (warn_slowpath_common+0x0/0x6c) from [<c001cf88>] (warn_slowpath_f)
 r8:00000228 r7:c03de574 r6:00000228 r5:00000000 r4:de8029c0                    
r3:00000009                                                                     
[<c001cf50>] (warn_slowpath_fmt+0x0/0x40) from [<c0065640>] (irq_domain_associa)
 r3:00000228 r2:c037fbdb                                                        
[<c00655a4>] (irq_domain_associate_many+0x0/0x1f0) from [<c03d48a4>] (register_)
[<c03d4360>] (register_intc_controller+0x0/0x984) from [<c03c6e68>] (sh73a0_ini)
[<c03c6e04>] (sh73a0_init_irq+0x0/0x1c0) from [<c03c261c>] (init_IRQ+0x1c/0x24) 
 r7:c08a90c0 r6:c03dd774 r5:c03e8000 r4:c041ba80                                
[<c03c2600>] (init_IRQ+0x0/0x24) from [<c03c1744>] (start_kernel+0x19c/0x2a0)   
[<c03c15a8>] (start_kernel+0x0/0x2a0) from [<41008040>] (0x41008040)            
 r7:c03f3b4c r6:c03dd770 r5:c03f047c r4:10c5387d                                
---[ end trace 1b75b31a2719ed1c ]---                                            
intc: domain association failure                                                
irq: irq_domain_associate_many(<no-node>, irqbaseU3, hwbaseU3, count=1)     
------------[ cut here ]------------                                            
WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
error: irq_desc already associated; irqU3 hwirq=0x229                         
Modules linked in:                                                              
Backtrace:                                                                      
[<c0012358>] (dump_backtrace+0x0/0x10c) from [<c02e7e1c>] (dump_stack+0x18/0x1c)
 r6:c0065640 r5:00000009 r4:c03e9ed8 r3:c0404908                                
[<c02e7e04>] (dump_stack+0x0/0x1c) from [<c001cecc>] (warn_slowpath_common+0x54)
[<c001ce78>] (warn_slowpath_common+0x0/0x6c) from [<c001cf88>] (warn_slowpath_f)
 r8:00000229 r7:c03de574 r6:00000229 r5:00000000 r4:de8029c0                    
r3:00000009                                                                     
[<c001cf50>] (warn_slowpath_fmt+0x0/0x40) from [<c0065640>] (irq_domain_associa)
 r3:00000229 r2:c037fbdb                                                        
[<c00655a4>] (irq_domain_associate_many+0x0/0x1f0) from [<c03d48a4>] (register_)
[<c03d4360>] (register_intc_controller+0x0/0x984) from [<c03c6e68>] (sh73a0_ini)
[<c03c6e04>] (sh73a0_init_irq+0x0/0x1c0) from [<c03c261c>] (init_IRQ+0x



Best regards
---
Kuninori Morimoto

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Tetsuyuki Kobayashi]

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

Hello, Paul

I applied the following 2 patches and got log on kzm9g board.
Please check attached log file.

(2012/08/20 12:13), Paul Mundt wrote:
> On Sun, Aug 19, 2012 at 06:14:41PM -0700, Kuninori Morimoto wrote:
>>
>> Hi Paul
>>
>> Thank you for your patch
>>
>>>> diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
>>>> index 32c26d7..8f32a13 100644
>>>> --- a/drivers/sh/intc/core.c
>>>> +++ b/drivers/sh/intc/core.c
>>>> @@ -355,7 +355,7 @@ int __init register_intc_controller(struct intc_desc *desc)
>>>>    			if (unlikely(res)) {
>>>>    				if (res == -EEXIST) {
>>>>    					res = irq_domain_associate(d->domain,
>>>> -								   irq, irq);
>>>> +								   irq2, irq2);
>>>>    					if (unlikely(res)) {
>>>>    						pr_err("domain association "
>>>>    						       "failure\n");
>>>
>>> I tried this patch but there is still the same error.
>>> I checked quickly by debugger, and I found the failing
>>> irq_domain_associate() is not called here (line 357) but the one at line
>>> 328.
>>
>> But, I got same result.
>>
>> This WARNING is indicating
>>> intc: domain association failure
>>
>> So, as kobayashi-san said,
>> it has happend on previous irq_domain_associate(), not here.
>>
> Can you post a boot log with the pr_debug() output in the irqdomain code
> enabled? You may need to add ignore_loglevel to your kernel command line.
>
> If that doesn't produce any further clues I'll have to find one of these
> boards to see what's going on.
>
> ---
>
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 49a7772..3b39c0e 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -1,5 +1,7 @@
>   #define pr_fmt(fmt)  "irq: " fmt
>
> +#define DEBUG
> +
>   #include <linux/debugfs.h>
>   #include <linux/hardirq.h>
>   #include <linux/interrupt.h>
>


[-- Attachment #2: 20120820_kzm9g_v36rc2_irqdomain.txt --]
[-- Type: text/plain, Size: 32787 bytes --]

Booting Linux on physical CPU 0
Linux version 3.6.0-rc2+ (koba@koba-linux2) (gcc version 4.6.2 20110921 (release) [ARM/embedded-4_6-branch revision 182083] (GNU Tools for ARM Embedded Processors) ) #101 SMP PREEMPT Mon Aug 20 13:08:04 JST 2012
CPU: ARMv7 Processor [412fc098] revision 8 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: kzm9g
debug: ignoring loglevel setting.
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 61440
free_area_init_node: node 0, pgdat c0489240, node_mem_map c04b9000
  Normal zone: 540 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 60900 pages, LIFO batch:15
bootconsole [early_ttySC4] enabled
PERCPU: Embedded 7 pages/cpu @c06d9000 s6592 r8192 d13888 u32768
pcpu-alloc: s6592 r8192 d13888 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 60900
Kernel command line: console=tty0 console=ttySC4,115200 root=/dev/nfs ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200 root=/dev/mmcblk0p2 mem=240m
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 240MB = 240MB total
Memory: 238488k/238488k available, 7272k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xcf800000 - 0xff000000   ( 760 MB)
    lowmem  : 0xc0000000 - 0xcf000000   ( 240 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc042d000   (4244 kB)
      .init : 0xc042d000 - 0xc04559c0   ( 163 kB)
      .data : 0xc0456000 - 0xc0489ea0   ( 208 kB)
       .bss : 0xc0489ec4 - 0xc04b8b84   ( 188 kB)
Preemptible hierarchical RCU implementation.
        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
NR_IRQS:16 nr_irqs:16 16
irq: Allocated domain of type 0 @0xce802800
intc: Registered controller 'sh73a0-intcs' with 77 IRQs
irq: Allocated domain of type 3 @0xce802940
irq: irq_domain_associate_many(<no-node>, irqbase=448, hwbase=448, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=449, hwbase=449, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=464, hwbase=464, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=465, hwbase=465, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=466, hwbase=466, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=467, hwbase=467, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=468, hwbase=468, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=472, hwbase=472, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=475, hwbase=475, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=476, hwbase=476, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=477, hwbase=477, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=479, hwbase=479, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=480, hwbase=480, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=492, hwbase=492, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=493, hwbase=493, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=494, hwbase=494, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=495, hwbase=495, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=500, hwbase=500, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=505, hwbase=505, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=516, hwbase=516, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=517, hwbase=517, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=518, hwbase=518, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=520, hwbase=520, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=521, hwbase=521, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=522, hwbase=522, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=523, hwbase=523, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=524, hwbase=524, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=525, hwbase=525, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=526, hwbase=526, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=432, hwbase=432, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=434, hwbase=434, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=436, hwbase=436, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=437, hwbase=437, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=438, hwbase=438, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=443, hwbase=443, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=444, hwbase=444, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=445, hwbase=445, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=552, hwbase=552, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=553, hwbase=553, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=554, hwbase=554, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=555, hwbase=555, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=556, hwbase=556, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=557, hwbase=557, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=584, hwbase=584, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=587, hwbase=587, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=588, hwbase=588, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=589, hwbase=589, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=590, hwbase=590, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=591, hwbase=591, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=592, hwbase=592, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=593, hwbase=593, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=594, hwbase=594, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=600, hwbase=600, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=601, hwbase=601, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=602, hwbase=602, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=603, hwbase=603, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=604, hwbase=604, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=608, hwbase=608, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=609, hwbase=609, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=615, hwbase=615, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=616, hwbase=616, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=618, hwbase=618, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=619, hwbase=619, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=620, hwbase=620, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=621, hwbase=621, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=623, hwbase=623, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=624, hwbase=624, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=625, hwbase=625, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=626, hwbase=626, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=627, hwbase=627, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=628, hwbase=628, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=629, hwbase=629, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=630, hwbase=630, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=631, hwbase=631, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=632, hwbase=632, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=633, hwbase=633, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=680, hwbase=680, count=1)
intc: Registered controller 'sh73a0-intca-irq-pins' with 32 IRQs
irq: Allocated domain of type 3 @0xce8029c0
irq: irq_domain_associate_many(<no-node>, irqbase=544, hwbase=544, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=545, hwbase=545, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=546, hwbase=546, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=547, hwbase=547, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=548, hwbase=548, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=549, hwbase=549, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=550, hwbase=550, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=551, hwbase=551, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=552, hwbase=552, count=1)
------------[ cut here ]------------
WARNING: at /proj/koba/kernel/linux.mainline/kernel/irq/irqdomain.c:431 irq_domain_associate_many+0xa8/0x200()
error: irq_desc already associated; irq=552 hwirq=0x228
Modules linked in:
Backtrace:
[<c0011f28>] (dump_backtrace+0x0/0x110) from [<c03421b0>] (dump_stack+0x18/0x1c)
 r6:c03e3c90 r5:000001af r4:c0457ec0 r3:c0472908
[<c0342198>] (dump_stack+0x0/0x1c) from [<c001cc90>] (warn_slowpath_common+0x54/0x6c)
[<c001cc3c>] (warn_slowpath_common+0x0/0x6c) from [<c001cd4c>] (warn_slowpath_fmt+0x38/0x40)
 r8:00000228 r7:c044c16c r6:00000000 r5:00000228 r4:ce8029c0
r3:00000009
[<c001cd14>] (warn_slowpath_fmt+0x0/0x40) from [<c0064770>] (irq_domain_associate_many+0xa8/0x200)
 r3:00000228 r2:c03e3d5e
[<c00646c8>] (irq_domain_associate_many+0x0/0x200) from [<c04422e4>] (register_intc_controller+0x51c/0x988)
[<c0441dc8>] (register_intc_controller+0x0/0x988) from [<c0433d80>] (sh73a0_init_irq+0x68/0x1cc)
[<c0433d18>] (sh73a0_init_irq+0x0/0x1cc) from [<c042f4dc>] (init_IRQ+0x1c/0x24)
 r8:4100406a r7:c06d6140 r6:c044b5bc r5:c0489f00 r4:c0456000
[<c042f4c0>] (init_IRQ+0x0/0x24) from [<c042d710>] (start_kernel+0x19c/0x31c)
[<c042d574>] (start_kernel+0x0/0x31c) from [<41008040>] (0x41008040)
 r7:c0461b64 r6:c044b5b8 r5:c045e47c r4:10c5387d
---[ end trace 1b75b31a2719ed1c ]---
intc: domain association failure
irq: irq_domain_associate_many(<no-node>, irqbase=553, hwbase=553, count=1)
------------[ cut here ]------------
WARNING: at /proj/koba/kernel/linux.mainline/kernel/irq/irqdomain.c:431 irq_domain_associate_many+0xa8/0x200()
error: irq_desc already associated; irq=553 hwirq=0x229
Modules linked in:
Backtrace:
[<c0011f28>] (dump_backtrace+0x0/0x110) from [<c03421b0>] (dump_stack+0x18/0x1c)
 r6:c03e3c90 r5:000001af r4:c0457ec0 r3:c0472908
[<c0342198>] (dump_stack+0x0/0x1c) from [<c001cc90>] (warn_slowpath_common+0x54/0x6c)
[<c001cc3c>] (warn_slowpath_common+0x0/0x6c) from [<c001cd4c>] (warn_slowpath_fmt+0x38/0x40)
 r8:00000229 r7:c044c16c r6:00000000 r5:00000229 r4:ce8029c0
r3:00000009
[<c001cd14>] (warn_slowpath_fmt+0x0/0x40) from [<c0064770>] (irq_domain_associate_many+0xa8/0x200)
 r3:00000229 r2:c03e3d5e
[<c00646c8>] (irq_domain_associate_many+0x0/0x200) from [<c04422e4>] (register_intc_controller+0x51c/0x988)
[<c0441dc8>] (register_intc_controller+0x0/0x988) from [<c0433d80>] (sh73a0_init_irq+0x68/0x1cc)
[<c0433d18>] (sh73a0_init_irq+0x0/0x1cc) from [<c042f4dc>] (init_IRQ+0x1c/0x24)
 r8:4100406a r7:c06d6140 r6:c044b5bc r5:c0489f00 r4:c0456000
[<c042f4c0>] (init_IRQ+0x0/0x24) from [<c042d710>] (start_kernel+0x19c/0x31c)
[<c042d574>] (start_kernel+0x0/0x31c) from [<41008040>] (0x41008040)
 r7:c0461b64 r6:c044b5b8 r5:c045e47c r4:10c5387d
---[ end trace 1b75b31a2719ed1d ]---
intc: domain association failure
irq: irq_domain_associate_many(<no-node>, irqbase=554, hwbase=554, count=1)
------------[ cut here ]------------
WARNING: at /proj/koba/kernel/linux.mainline/kernel/irq/irqdomain.c:431 irq_domain_associate_many+0xa8/0x200()
error: irq_desc already associated; irq=554 hwirq=0x22a
Modules linked in:
Backtrace:
[<c0011f28>] (dump_backtrace+0x0/0x110) from [<c03421b0>] (dump_stack+0x18/0x1c)
 r6:c03e3c90 r5:000001af r4:c0457ec0 r3:c0472908
[<c0342198>] (dump_stack+0x0/0x1c) from [<c001cc90>] (warn_slowpath_common+0x54/0x6c)
[<c001cc3c>] (warn_slowpath_common+0x0/0x6c) from [<c001cd4c>] (warn_slowpath_fmt+0x38/0x40)
 r8:0000022a r7:c044c16c r6:00000000 r5:0000022a r4:ce8029c0
r3:00000009
[<c001cd14>] (warn_slowpath_fmt+0x0/0x40) from [<c0064770>] (irq_domain_associate_many+0xa8/0x200)
 r3:0000022a r2:c03e3d5e
[<c00646c8>] (irq_domain_associate_many+0x0/0x200) from [<c04422e4>] (register_intc_controller+0x51c/0x988)
[<c0441dc8>] (register_intc_controller+0x0/0x988) from [<c0433d80>] (sh73a0_init_irq+0x68/0x1cc)
[<c0433d18>] (sh73a0_init_irq+0x0/0x1cc) from [<c042f4dc>] (init_IRQ+0x1c/0x24)
 r8:4100406a r7:c06d6140 r6:c044b5bc r5:c0489f00 r4:c0456000
[<c042f4c0>] (init_IRQ+0x0/0x24) from [<c042d710>] (start_kernel+0x19c/0x31c)
[<c042d574>] (start_kernel+0x0/0x31c) from [<41008040>] (0x41008040)
 r7:c0461b64 r6:c044b5b8 r5:c045e47c r4:10c5387d
---[ end trace 1b75b31a2719ed1e ]---
intc: domain association failure
irq: irq_domain_associate_many(<no-node>, irqbase=555, hwbase=555, count=1)
------------[ cut here ]------------
WARNING: at /proj/koba/kernel/linux.mainline/kernel/irq/irqdomain.c:431 irq_domain_associate_many+0xa8/0x200()
error: irq_desc already associated; irq=555 hwirq=0x22b
Modules linked in:
Backtrace:
[<c0011f28>] (dump_backtrace+0x0/0x110) from [<c03421b0>] (dump_stack+0x18/0x1c)
 r6:c03e3c90 r5:000001af r4:c0457ec0 r3:c0472908
[<c0342198>] (dump_stack+0x0/0x1c) from [<c001cc90>] (warn_slowpath_common+0x54/0x6c)
[<c001cc3c>] (warn_slowpath_common+0x0/0x6c) from [<c001cd4c>] (warn_slowpath_fmt+0x38/0x40)
 r8:0000022b r7:c044c16c r6:00000000 r5:0000022b r4:ce8029c0
r3:00000009
[<c001cd14>] (warn_slowpath_fmt+0x0/0x40) from [<c0064770>] (irq_domain_associate_many+0xa8/0x200)
 r3:0000022b r2:c03e3d5e
[<c00646c8>] (irq_domain_associate_many+0x0/0x200) from [<c04422e4>] (register_intc_controller+0x51c/0x988)
[<c0441dc8>] (register_intc_controller+0x0/0x988) from [<c0433d80>] (sh73a0_init_irq+0x68/0x1cc)
[<c0433d18>] (sh73a0_init_irq+0x0/0x1cc) from [<c042f4dc>] (init_IRQ+0x1c/0x24)
 r8:4100406a r7:c06d6140 r6:c044b5bc r5:c0489f00 r4:c0456000
[<c042f4c0>] (init_IRQ+0x0/0x24) from [<c042d710>] (start_kernel+0x19c/0x31c)
[<c042d574>] (start_kernel+0x0/0x31c) from [<41008040>] (0x41008040)
 r7:c0461b64 r6:c044b5b8 r5:c045e47c r4:10c5387d
---[ end trace 1b75b31a2719ed1f ]---
intc: domain association failure
irq: irq_domain_associate_many(<no-node>, irqbase=556, hwbase=556, count=1)
------------[ cut here ]------------
WARNING: at /proj/koba/kernel/linux.mainline/kernel/irq/irqdomain.c:431 irq_domain_associate_many+0xa8/0x200()
error: irq_desc already associated; irq=556 hwirq=0x22c
Modules linked in:
Backtrace:
[<c0011f28>] (dump_backtrace+0x0/0x110) from [<c03421b0>] (dump_stack+0x18/0x1c)
 r6:c03e3c90 r5:000001af r4:c0457ec0 r3:c0472908
[<c0342198>] (dump_stack+0x0/0x1c) from [<c001cc90>] (warn_slowpath_common+0x54/0x6c)
[<c001cc3c>] (warn_slowpath_common+0x0/0x6c) from [<c001cd4c>] (warn_slowpath_fmt+0x38/0x40)
 r8:0000022c r7:c044c16c r6:00000000 r5:0000022c r4:ce8029c0
r3:00000009
[<c001cd14>] (warn_slowpath_fmt+0x0/0x40) from [<c0064770>] (irq_domain_associate_many+0xa8/0x200)
 r3:0000022c r2:c03e3d5e
[<c00646c8>] (irq_domain_associate_many+0x0/0x200) from [<c04422e4>] (register_intc_controller+0x51c/0x988)
[<c0441dc8>] (register_intc_controller+0x0/0x988) from [<c0433d80>] (sh73a0_init_irq+0x68/0x1cc)
[<c0433d18>] (sh73a0_init_irq+0x0/0x1cc) from [<c042f4dc>] (init_IRQ+0x1c/0x24)
 r8:4100406a r7:c06d6140 r6:c044b5bc r5:c0489f00 r4:c0456000
[<c042f4c0>] (init_IRQ+0x0/0x24) from [<c042d710>] (start_kernel+0x19c/0x31c)
[<c042d574>] (start_kernel+0x0/0x31c) from [<41008040>] (0x41008040)
 r7:c0461b64 r6:c044b5b8 r5:c045e47c r4:10c5387d
---[ end trace 1b75b31a2719ed20 ]---
intc: domain association failure
irq: irq_domain_associate_many(<no-node>, irqbase=557, hwbase=557, count=1)
------------[ cut here ]------------
WARNING: at /proj/koba/kernel/linux.mainline/kernel/irq/irqdomain.c:431 irq_domain_associate_many+0xa8/0x200()
error: irq_desc already associated; irq=557 hwirq=0x22d
Modules linked in:
Backtrace:
[<c0011f28>] (dump_backtrace+0x0/0x110) from [<c03421b0>] (dump_stack+0x18/0x1c)
 r6:c03e3c90 r5:000001af r4:c0457ec0 r3:c0472908
[<c0342198>] (dump_stack+0x0/0x1c) from [<c001cc90>] (warn_slowpath_common+0x54/0x6c)
[<c001cc3c>] (warn_slowpath_common+0x0/0x6c) from [<c001cd4c>] (warn_slowpath_fmt+0x38/0x40)
 r8:0000022d r7:c044c16c r6:00000000 r5:0000022d r4:ce8029c0
r3:00000009
[<c001cd14>] (warn_slowpath_fmt+0x0/0x40) from [<c0064770>] (irq_domain_associate_many+0xa8/0x200)
 r3:0000022d r2:c03e3d5e
[<c00646c8>] (irq_domain_associate_many+0x0/0x200) from [<c04422e4>] (register_intc_controller+0x51c/0x988)
[<c0441dc8>] (register_intc_controller+0x0/0x988) from [<c0433d80>] (sh73a0_init_irq+0x68/0x1cc)
[<c0433d18>] (sh73a0_init_irq+0x0/0x1cc) from [<c042f4dc>] (init_IRQ+0x1c/0x24)
 r8:4100406a r7:c06d6140 r6:c044b5bc r5:c0489f00 r4:c0456000
[<c042f4c0>] (init_IRQ+0x0/0x24) from [<c042d710>] (start_kernel+0x19c/0x31c)
[<c042d574>] (start_kernel+0x0/0x31c) from [<41008040>] (0x41008040)
 r7:c0461b64 r6:c044b5b8 r5:c045e47c r4:10c5387d
---[ end trace 1b75b31a2719ed21 ]---
intc: domain association failure
irq: irq_domain_associate_many(<no-node>, irqbase=558, hwbase=558, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=559, hwbase=559, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=928, hwbase=928, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=929, hwbase=929, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=930, hwbase=930, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=931, hwbase=931, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=932, hwbase=932, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=933, hwbase=933, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=934, hwbase=934, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=935, hwbase=935, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=936, hwbase=936, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=937, hwbase=937, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=938, hwbase=938, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=939, hwbase=939, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=940, hwbase=940, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=941, hwbase=941, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=942, hwbase=942, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=943, hwbase=943, count=1)
intc: Registered controller 'sh73a0-pint0' with 32 IRQs
irq: Allocated domain of type 3 @0xce802a00
irq: irq_domain_associate_many(<no-node>, irqbase=700, hwbase=700, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=701, hwbase=701, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=702, hwbase=702, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=703, hwbase=703, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=704, hwbase=704, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=705, hwbase=705, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=706, hwbase=706, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=707, hwbase=707, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=708, hwbase=708, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=709, hwbase=709, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=710, hwbase=710, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=711, hwbase=711, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=712, hwbase=712, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=713, hwbase=713, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=714, hwbase=714, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=715, hwbase=715, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=716, hwbase=716, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=717, hwbase=717, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=718, hwbase=718, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=719, hwbase=719, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=720, hwbase=720, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=721, hwbase=721, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=722, hwbase=722, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=723, hwbase=723, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=724, hwbase=724, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=725, hwbase=725, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=726, hwbase=726, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=727, hwbase=727, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=728, hwbase=728, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=729, hwbase=729, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=730, hwbase=730, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=731, hwbase=731, count=1)
intc: Registered controller 'sh73a0-pint1' with 8 IRQs
irq: Allocated domain of type 3 @0xce802ac0
irq: irq_domain_associate_many(<no-node>, irqbase=732, hwbase=732, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=733, hwbase=733, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=734, hwbase=734, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=735, hwbase=735, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=736, hwbase=736, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=737, hwbase=737, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=738, hwbase=738, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=739, hwbase=739, count=1)
sched_clock: 32 bits at 128 Hz, resolution 7812500ns, wraps every 3489660920ms
Console: colour dummy device 80x30
console [tty0] enabled
 sh_tmu.0: used for clock events
 sh_tmu.0: used for periodic clock events
 sh_tmu.1: used as clock source
Calibrating delay loop... 2384.28 BogoMIPS (lpj=9314304)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
smp_twd: clock not found: -2
Calibrating local timer... 291.93MHz.
Setting up static identity map for 0x41347a30 - 0x41347a88
CPU1: failed to come online
Brought up 1 CPUs
SMP: Total of 1 processors activated (2384.28 BogoMIPS).
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
sh_pfc gpio: sh73a0_pfc handling gpio 0 -> 928
sh_pfc core: sh73a0_pfc support registered
pinctrl-sh_pfc pinctrl: Use of GPIO API for function requests is deprecated, convert to pinctrl
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x42460000, Cache size: 524288 B
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c-sh_mobile i2c-sh_mobile.0: I2C adapter 0 with bus speed 100000 Hz
i2c-sh_mobile i2c-sh_mobile.1: I2C adapter 1 with bus speed 100000 Hz
i2c-sh_mobile i2c-sh_mobile.2: I2C adapter 2 with bus speed 100000 Hz
pcf857x 3-0020:
i2c-sh_mobile i2c-sh_mobile.3: I2C adapter 3 with bus speed 100000 Hz
i2c-sh_mobile i2c-sh_mobile.4: I2C adapter 4 with bus speed 100000 Hz
Advanced Linux Sound Architecture Driver Version 1.0.25.
NET: Registered protocol family 23
Switching to clocksource sh_tmu.1
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 98304 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
msgmni has been set to 465
io scheduler noop registered (default)
Console: switching to colour frame buffer device 100x30
sh_mobile_lcdc_fb sh_mobile_lcdc_fb.0: registered sh_mobile_lcdc_fb.0/mainlcd as 800x480 16bpp.
SuperH SCI(F) driver initialized
sh-sci.0: ttySC0 at MMIO 0xe6c40000 (irq = 104) is a scifa
console [ttySC4] enabled, bootconsole disabled
console [ttySC4] enabled, bootconsole disabled
sh-sci.1: ttySC1 at MMIO 0xe6c50000 (irq = 105) is a scifa
sh-sci.2: ttySC2 at MMIO 0xe6c60000 (irq = 106) is a scifa
sh-sci.3: ttySC3 at MMIO 0xe6c70000 (irq = 107) is a scifa
sh-sci.4: ttySC4 at MMIO 0xe6c80000 (irq = 110) is a scifa
sh-sci.5: ttySC5 at MMIO 0xe6cb0000 (irq = 111) is a scifa
sh-sci.6: ttySC6 at MMIO 0xe6cc0000 (irq = 188) is a scifa
sh-sci.7: ttySC7 at MMIO 0xe6cd0000 (irq = 175) is a scifa
sh-sci.8: ttySC8 at MMIO 0xe6c30000 (irq = 112) is a scifb
smsc911x: Driver version 2008-10-21
libphy: smsc911x-mdio: probed
smsc911x smsc911x.0: eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=smsc911x-0:01, irq=-1)
smsc911x smsc911x.0: eth0: MAC Address: 00:01:9b:04:04:10
r8a66597_hcd r8a66597_hcd.0: USB Host Controller
r8a66597_hcd r8a66597_hcd.0: new USB bus registered, assigned bus number 1
r8a66597_hcd r8a66597_hcd.0: irq 417, io base 0x10010000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
renesas_usbhs renesas_usbhs: gadget probed
renesas_usbhs renesas_usbhs: probed
input: gpio-keys-polled as /devices/platform/gpio-keys-polled.0/input/input0
input: st1232-touchscreen as /devices/platform/i2c-sh_mobile.1/i2c-1/1-0055/input/input1
rtc-rs5c372 0-0032: r2025sd found, am/pm, driver version 0.6
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0
i2c /dev entries driver
sh_mobile_sdhi sh_mobile_sdhi.0: mmc0 base at 0xee100000 clock rate 0 MHz
sh_mobile_sdhi sh_mobile_sdhi.2: mmc1 base at 0xee140000 clock rate 0 MHz
usb 1-2: new high-speed USB device number 2 using r8a66597_hcd
sh_mmcif sh_mmcif.0: driver version 2010-04-28
sh_pfc gpio: attaching to GPIO chip sh73a0_pfc
sh_cmt sh_cmt.10: used for clock events
sh_cmt sh_cmt.10: used as clock source
sh_tmu sh_tmu.0: kept as earlytimer
sh_tmu sh_tmu.1: kept as earlytimer
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
platform asoc-simple-card.0: Driver asoc-simple-card requests probe deferral
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 2
mmc0: new high speed SDHC card at address b368
Registering SWP/SWPB emulation handler
mmcblk0: mmc0:b368 LEXAR 3.73 GiB
 mmcblk0: p1 p2
rtc-rs5c372 0-0032: setting system clock to 2012-08-20 04:08:54 UTC (1345435734)
asoc-simple-card asoc-simple-card.0:  ak4642-hifi <-> fsia-dai mapping ok
scsi0 : usb-storage 1-2:1.0
smsc911x smsc911x.0: eth0: SMSC911x/921x identified at 0xcf9e8000, IRQ: 419
Sending DHCP requests .mmc1: new high speed SDHC card at address b368
mmcblk1: mmc1:b368 SD04G 3.66 GiB
 mmcblk1: p1 p2 p3
usb 1-2: address 2, EndpointAddress 0x02 use DMA FIFO
usb 1-2: address 2, EndpointAddress 0x81 use DMA FIFO
[sched_delayed] sched: RT throttling activated
scsi 0:0:0:0: Direct-Access              Patriot Memory   PMAP PQ: 0 ANSI: 0 CCS
mmc2: new high speed MMC card at address 0001
mmcblk2: mmc2:0001 M4G1EM 3.72 GiB
 mmcblk2: p1
sd 0:0:0:0: [sda] 7831552 512-byte logical blocks: (4.00 GB/3.73 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 0:0:0:0: [sda] No Caching mode page present
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] No Caching mode page present
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2
sd 0:0:0:0: [sda] No Caching mode page present
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Attached SCSI removable disk
.., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.1.35
IP-Config: Complete:
     device=eth0, addr=192.168.1.35, mask=255.255.255.0, gw=192.168.1.62
     host=192.168.1.35, domain=kmckk.jp, nis-domain=(none)
     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
ALSA device list:
  #0: FSI2A-AK4648
EXT3-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)
EXT2-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)
EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 179:2.
Freeing init memory: 160K
modprobe: FATAL: Could not load /lib/modules/3.6.0-rc2+/modules.dep: No such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc2+/modules.dep: No such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc2+/modules.dep: No such file or directory

init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: plymouth main process (469) killed by SEGV signal
init: plymouth-splash main process (3074) terminated with status 2
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: failsafe main process (3130) killed by TERM signal
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory

init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
 * Starting internet superserver inetd       init: Temporary process spawn error: No such file or directory
                                                                               init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
                                                                         [ OK ]
Last login: Mon Aug 20 00:30:39 UTC 2012 on tty1
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
Welcome to Linaro 12.08 (development branch) (GNU/Linux 3.6.0-rc2+ armv7l)

 * Documentation:  https://wiki.linaro.org/
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
init: tty1 main process (3262) killed by TERM signal
root@linaro-alip:~#

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Paul Mundt]

On Sun, Aug 19, 2012 at 09:19:34PM -0700, Kuninori Morimoto wrote:
> 
> Hi Paul
> 
> > Can you post a boot log with the pr_debug() output in the irqdomain code
> > enabled? You may need to add ignore_loglevel to your kernel command line.
> > 
> > If that doesn't produce any further clues I'll have to find one of these
> > boards to see what's going on.
> 
> This is my log
> 
> NR_IRQS:16 nr_irqs:16 16                                                        
> irq: Allocated domain of type 0 @0xde802800                                     
> intc: Registered controller 'sh73a0-intcs' with 77 IRQs                         
> irq: Allocated domain of type 3 @0xde802940                                     
..
> irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)     
..
> intc: Registered controller 'sh73a0-intca-irq-pins' with 32 IRQs                
> irq: Allocated domain of type 3 @0xde8029c0                                     
> irq: irq_domain_associate_many(<no-node>, irqbaseT4, hwbaseT4, count=1)     
> irq: irq_domain_associate_many(<no-node>, irqbaseT5, hwbaseT5, count=1)     
> irq: irq_domain_associate_many(<no-node>, irqbaseT6, hwbaseT6, count=1)     
> irq: irq_domain_associate_many(<no-node>, irqbaseT7, hwbaseT7, count=1)     
> irq: irq_domain_associate_many(<no-node>, irqbaseT8, hwbaseT8, count=1)     
> irq: irq_domain_associate_many(<no-node>, irqbaseT9, hwbaseT9, count=1)     
> irq: irq_domain_associate_many(<no-node>, irqbaseU0, hwbaseU0, count=1)     
> irq: irq_domain_associate_many(<no-node>, irqbaseU1, hwbaseU1, count=1)     
> irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)     
> ------------[ cut here ]------------                                            
> WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
> error: irq_desc already associated; irqU2 hwirq=0x228                         

Well, that's certainly a valid bug. hwirq 552 is already bound to the
previous controller, and the vector in question is being registered a
second time under another controller. This looks to be RTDMAC_2_DEI6 (0x1300),
but the rest descends in to macro hell, so it's not obvious why the same
vector is being registered in multiple places.

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Kuninori Morimoto]

Hi Paul
Cc Magnus, Kobayashi-san

> > irq: irq_domain_associate_many(<no-node>, irqbaseT5, hwbaseT5, count=1)     
> > irq: irq_domain_associate_many(<no-node>, irqbaseT6, hwbaseT6, count=1)     
> > irq: irq_domain_associate_many(<no-node>, irqbaseT7, hwbaseT7, count=1)     
> > irq: irq_domain_associate_many(<no-node>, irqbaseT8, hwbaseT8, count=1)     
> > irq: irq_domain_associate_many(<no-node>, irqbaseT9, hwbaseT9, count=1)     
> > irq: irq_domain_associate_many(<no-node>, irqbaseU0, hwbaseU0, count=1)     
> > irq: irq_domain_associate_many(<no-node>, irqbaseU1, hwbaseU1, count=1)     
> > irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)     
> > ------------[ cut here ]------------                                            
> > WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
> > error: irq_desc already associated; irqU2 hwirq=0x228                         
> 
> Well, that's certainly a valid bug. hwirq 552 is already bound to the
> previous controller, and the vector in question is being registered a
> second time under another controller. This looks to be RTDMAC_2_DEI6 (0x1300),
> but the rest descends in to macro hell, so it's not obvious why the same
> vector is being registered in multiple places.


I'm not sure why, but this patch solved problem ?

-------------------------------------------
diff --git a/arch/arm/mach-shmobile/intc-sh73a0.c b/arch/arm/mach-shmobile/intc-
index ee44740..a6eae4f 100644
--- a/arch/arm/mach-shmobile/intc-sh73a0.c
+++ b/arch/arm/mach-shmobile/intc-sh73a0.c
@@ -259,7 +259,7 @@ static int sh73a0_set_wake(struct irq_data *data, unsigned i
        return 0; /* always allow wakeup */
 }
 
-#define RELOC_BASE 0x1000
+#define RELOC_BASE 0x1200
 
 /* INTCA IRQ pins at INTCS + 0x1000 to make space for GIC+INTC handling */
 #define INTCS_VECT_RELOC(n, vect) INTCS_VECT((n), (vect) + RELOC_BASE)



Best regards
---
Kuninori Morimoto

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Paul Mundt]

On Sun, Aug 19, 2012 at 09:45:33PM -0700, Kuninori Morimoto wrote:
> 
> Hi Paul
> Cc Magnus, Kobayashi-san
> 
> > > irq: irq_domain_associate_many(<no-node>, irqbaseT5, hwbaseT5, count=1)     
> > > irq: irq_domain_associate_many(<no-node>, irqbaseT6, hwbaseT6, count=1)     
> > > irq: irq_domain_associate_many(<no-node>, irqbaseT7, hwbaseT7, count=1)     
> > > irq: irq_domain_associate_many(<no-node>, irqbaseT8, hwbaseT8, count=1)     
> > > irq: irq_domain_associate_many(<no-node>, irqbaseT9, hwbaseT9, count=1)     
> > > irq: irq_domain_associate_many(<no-node>, irqbaseU0, hwbaseU0, count=1)     
> > > irq: irq_domain_associate_many(<no-node>, irqbaseU1, hwbaseU1, count=1)     
> > > irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)     
> > > ------------[ cut here ]------------                                            
> > > WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
> > > error: irq_desc already associated; irqU2 hwirq=0x228                         
> > 
> > Well, that's certainly a valid bug. hwirq 552 is already bound to the
> > previous controller, and the vector in question is being registered a
> > second time under another controller. This looks to be RTDMAC_2_DEI6 (0x1300),
> > but the rest descends in to macro hell, so it's not obvious why the same
> > vector is being registered in multiple places.
> 
> 
> I'm not sure why, but this patch solved problem ?
> 
I'll let Magnus figure this one out, as it was his hack in the first
place. At least we know the irqdomain code isn't at fault anymore.

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Tetsuyuki Kobayashi]

Hello

(2012/08/20 13:45), Kuninori Morimoto wrote:
> 
> Hi Paul
> Cc Magnus, Kobayashi-san
> 
>>> irq: irq_domain_associate_many(<no-node>, irqbaseT5, hwbaseT5, count=1)
>>> irq: irq_domain_associate_many(<no-node>, irqbaseT6, hwbaseT6, count=1)
>>> irq: irq_domain_associate_many(<no-node>, irqbaseT7, hwbaseT7, count=1)
>>> irq: irq_domain_associate_many(<no-node>, irqbaseT8, hwbaseT8, count=1)
>>> irq: irq_domain_associate_many(<no-node>, irqbaseT9, hwbaseT9, count=1)
>>> irq: irq_domain_associate_many(<no-node>, irqbaseU0, hwbaseU0, count=1)
>>> irq: irq_domain_associate_many(<no-node>, irqbaseU1, hwbaseU1, count=1)
>>> irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)
>>> ------------[ cut here ]------------
>>> WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
>>> error: irq_desc already associated; irqU2 hwirq=0x228
>>
>> Well, that's certainly a valid bug. hwirq 552 is already bound to the
>> previous controller, and the vector in question is being registered a
>> second time under another controller. This looks to be RTDMAC_2_DEI6 (0x1300),
>> but the rest descends in to macro hell, so it's not obvious why the same
>> vector is being registered in multiple places.
> 
> 
> I'm not sure why, but this patch solved problem ?
> 
> -------------------------------------------
> diff --git a/arch/arm/mach-shmobile/intc-sh73a0.c b/arch/arm/mach-shmobile/intc-
> index ee44740..a6eae4f 100644
> --- a/arch/arm/mach-shmobile/intc-sh73a0.c
> +++ b/arch/arm/mach-shmobile/intc-sh73a0.c
> @@ -259,7 +259,7 @@ static int sh73a0_set_wake(struct irq_data *data, unsigned i
>          return 0; /* always allow wakeup */
>   }
>   
> -#define RELOC_BASE 0x1000
> +#define RELOC_BASE 0x1200
>   
>   /* INTCA IRQ pins at INTCS + 0x1000 to make space for GIC+INTC handling */
>   #define INTCS_VECT_RELOC(n, vect) INTCS_VECT((n), (vect) + RELOC_BASE)
> 
> 

FYI, 
I tried this patch, too. I got the following log. It seems no conflicts.


NR_IRQS:16 nr_irqs:16 16
irq: Allocated domain of type 0 @0xce802800
intc: Registered controller 'sh73a0-intcs' with 77 IRQs
irq: Allocated domain of type 3 @0xce802940
irq: irq_domain_associate_many(<no-node>, irqbaseD8, hwbaseD8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseD9, hwbaseD9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseF4, hwbaseF4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseF5, hwbaseF5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseF6, hwbaseF6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseF7, hwbaseF7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseF8, hwbaseF8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseG2, hwbaseG2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseG5, hwbaseG5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseG6, hwbaseG6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseG7, hwbaseG7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseG9, hwbaseG9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseH0, hwbaseH0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseI2, hwbaseI2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseI3, hwbaseI3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseI4, hwbaseI4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseI5, hwbaseI5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseP0, hwbaseP0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseP5, hwbaseP5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseQ6, hwbaseQ6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseQ7, hwbaseQ7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseQ8, hwbaseQ8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR0, hwbaseR0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR1, hwbaseR1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR2, hwbaseR2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR3, hwbaseR3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR4, hwbaseR4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR5, hwbaseR5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR6, hwbaseR6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseC2, hwbaseC2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseC4, hwbaseC4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseC6, hwbaseC6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseC7, hwbaseC7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseC8, hwbaseC8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseD3, hwbaseD3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseD4, hwbaseD4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseD5, hwbaseD5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseU3, hwbaseU3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseU4, hwbaseU4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseU5, hwbaseU5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseU6, hwbaseU6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseU7, hwbaseU7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseX4, hwbaseX4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseX7, hwbaseX7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseX8, hwbaseX8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseX9, hwbaseX9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseY0, hwbaseY0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseY1, hwbaseY1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseY2, hwbaseY2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseY3, hwbaseY3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseY4, hwbaseY4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase`0, hwbase`0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase`1, hwbase`1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase`2, hwbase`2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase`3, hwbase`3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase`4, hwbase`4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase`8, hwbase`8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase`9, hwbase`9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasea5, hwbasea5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasea6, hwbasea6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasea8, hwbasea8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasea9, hwbasea9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseb0, hwbaseb0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseb1, hwbaseb1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseb3, hwbaseb3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseb4, hwbaseb4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseb5, hwbaseb5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseb6, hwbaseb6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseb7, hwbaseb7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseb8, hwbaseb8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseb9, hwbaseb9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasec0, hwbasec0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasec1, hwbasec1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasec2, hwbasec2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasec3, hwbasec3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseh0, hwbaseh0, count=1)
intc: Registered controller 'sh73a0-intca-irq-pins' with 32 IRQs
irq: Allocated domain of type 3 @0xce8029c0
irq: irq_domain_associate_many(<no-node>, irqbaseV0, hwbaseV0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseV1, hwbaseV1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseV2, hwbaseV2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseV3, hwbaseV3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseV4, hwbaseV4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseV5, hwbaseV5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseV6, hwbaseV6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseV7, hwbaseV7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseV8, hwbaseV8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseV9, hwbaseV9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseW0, hwbaseW0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseW1, hwbaseW1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseW2, hwbaseW2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseW3, hwbaseW3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseW4, hwbaseW4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseW5, hwbaseW5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase”4, hwbase”4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase”5, hwbase”5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase”6, hwbase”6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase”7, hwbase”7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase”8, hwbase”8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase”9, hwbase”9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•0, hwbase•0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•1, hwbase•1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•2, hwbase•2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•3, hwbase•3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•4, hwbase•4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•5, hwbase•5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•6, hwbase•6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•7, hwbase•7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•8, hwbase•8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase•9, hwbase•9, count=1)
intc: Registered controller 'sh73a0-pint0' with 32 IRQs
irq: Allocated domain of type 3 @0xce802a00
irq: irq_domain_associate_many(<no-node>, irqbasep0, hwbasep0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasep1, hwbasep1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasep2, hwbasep2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasep3, hwbasep3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasep4, hwbasep4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasep5, hwbasep5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasep6, hwbasep6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasep7, hwbasep7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasep8, hwbasep8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbasep9, hwbasep9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq0, hwbaseq0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq1, hwbaseq1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq2, hwbaseq2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq3, hwbaseq3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq4, hwbaseq4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq5, hwbaseq5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq6, hwbaseq6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq7, hwbaseq7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq8, hwbaseq8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseq9, hwbaseq9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser0, hwbaser0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser1, hwbaser1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser2, hwbaser2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser3, hwbaser3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser4, hwbaser4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser5, hwbaser5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser6, hwbaser6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser7, hwbaser7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser8, hwbaser8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaser9, hwbaser9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbases0, hwbases0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbases1, hwbases1, count=1)
intc: Registered controller 'sh73a0-pint1' with 8 IRQs
irq: Allocated domain of type 3 @0xce802ac0
irq: irq_domain_associate_many(<no-node>, irqbases2, hwbases2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbases3, hwbases3, count=1)
irq: irq_domain_associate_many(<no-node>, irqbases4, hwbases4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbases5, hwbases5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbases6, hwbases6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbases7, hwbases7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbases8, hwbases8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbases9, hwbases9, count=1)
sched_clock: 32 bits at 128 Hz, resolution 7812500ns, wraps every 3489660920ms
Console: colour dummy device 80x30
console [tty0] enabled

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Kuninori Morimoto]

Hi Kobayashi-san

> > -------------------------------------------
> > diff --git a/arch/arm/mach-shmobile/intc-sh73a0.c b/arch/arm/mach-shmobile/intc-
> > index ee44740..a6eae4f 100644
> > --- a/arch/arm/mach-shmobile/intc-sh73a0.c
> > +++ b/arch/arm/mach-shmobile/intc-sh73a0.c
> > @@ -259,7 +259,7 @@ static int sh73a0_set_wake(struct irq_data *data, unsigned i
> >          return 0; /* always allow wakeup */
> >   }
> >   
> > -#define RELOC_BASE 0x1000
> > +#define RELOC_BASE 0x1200
> >   
> >   /* INTCA IRQ pins at INTCS + 0x1000 to make space for GIC+INTC handling */
> >   #define INTCS_VECT_RELOC(n, vect) INTCS_VECT((n), (vect) + RELOC_BASE)
> > 
> > 
> 
> FYI, 
> I tried this patch, too. I got the following log. It seems no conflicts.

Thank you for your checking/testing

Best regards
---
Kuninori Morimoto

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Kuninori Morimoto]

Hi Paul

> > I'm not sure why, but this patch solved problem ?
> > 
> I'll let Magnus figure this one out, as it was his hack in the first

Thank you !

> place. At least we know the irqdomain code isn't at fault anymore.

We have irq2 fix patch for multi-evt from you ?
        ~~~~

Best regards
---
Kuninori Morimoto

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Paul Mundt]

On Sun, Aug 19, 2012 at 11:24:51PM -0700, Kuninori Morimoto wrote:
> 
> Hi Paul
> 
> > > I'm not sure why, but this patch solved problem ?
> > > 
> > I'll let Magnus figure this one out, as it was his hack in the first
> 
> Thank you !
> 
> > place. At least we know the irqdomain code isn't at fault anymore.
> 
> We have irq2 fix patch for multi-evt from you ?
>         ~~~~
> 
Yes, I'll be sending that to Linus for -rc3.

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Tetsuyuki Kobayashi]

Hello, goda-san.

(2012/08/20 13:45), Kuninori Morimoto wrote:

> I'm not sure why, but this patch solved problem ?
> 
> -------------------------------------------
> diff --git a/arch/arm/mach-shmobile/intc-sh73a0.c b/arch/arm/mach-shmobile/intc-
> index ee44740..a6eae4f 100644
> --- a/arch/arm/mach-shmobile/intc-sh73a0.c
> +++ b/arch/arm/mach-shmobile/intc-sh73a0.c
> @@ -259,7 +259,7 @@ static int sh73a0_set_wake(struct irq_data *data, unsigned i
>          return 0; /* always allow wakeup */
>   }
>   
> -#define RELOC_BASE 0x1000
> +#define RELOC_BASE 0x1200
>   
>   /* INTCA IRQ pins at INTCS + 0x1000 to make space for GIC+INTC handling */
>   #define INTCS_VECT_RELOC(n, vect) INTCS_VECT((n), (vect) + RELOC_BASE)

After applying this patch on kzm9g board, I got this error regarding eMMC.
I think this is another problem.


Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd\0000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 1    Not tainted  (3.6.0-rc2+ #103)
PC is at sh_mmcif_irqt+0x20/0xb30
LR is at irq_thread+0x94/0x16c
pc : [<c0264b7c>]    lr : [<c0061608>]    psr: 60000113
sp : ce9f1f30  ip : ce9f1f80  fp : ce9f1f7c
r10: 00000000  r9 : cea426f8  r8 : ce9f5f60
r7 : ce9f0000  r6 : ce9f0000  r5 : 00000000  r4 : cea426c0
r3 : c0264b5c  r2 : 00000000  r1 : cea426c0  r0 : cea426f8
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 4fb7404a  DAC: 00000015
Process irq/173-sh_mmc: (pid: 397, stack limit = 0xce9f02f0)
Stack: (0xce9f1f30 to 0xce9f2000)
1f20:                                     c03462d0 c0040bfc cea426c0 c0455380
1f40: c0461db8 ce9f5f40 ce80ea40 ce9f0000 ce9f0000 ce9f5f40 ce80ea40 ce9f0000
1f60: ce9f0000 ce9f5f60 00000000 00000000 ce9f1fb4 ce9f1f80 c0061608 c0264b68
1f80: ce9f5f40 ce9f1f84 c00614a8 00000000 ce84bd70 ce9f5f40 c0061574 00000013
1fa0: 00000000 00000000 ce9f1ff4 ce9f1fb8 c00386c0 c0061580 00000000 00000000
1fc0: ce9f5f40 00000000 00000000 00000000 ce9f1fd0 ce9f1fd0 00000000 ce84bd70
1fe0: c003862c c0021910 00000000 ce9f1ff8 c0021910 c0038638 00000000 00000000
Backtrace:
[<c0264b5c>] (sh_mmcif_irqt+0x0/0xb30) from [<c0061608>] (irq_thread+0x94/0x16c)
[<c0061574>] (irq_thread+0x0/0x16c) from [<c00386c0>] (kthread+0x94/0xa0)
[<c003862c>] (kthread+0x0/0xa0) from [<c0021910>] (do_exit+0x0/0x700)
 r6:c0021910 r5:c003862c r4:ce84bd70
Code: e5915004 e2819038 e1a04001 e1a00009 (e595a008)
---[ end trace 2f02388ade397924 ]---
Unable to handle kernel paging request at virtual address fffffffc
pgd = c0004000
[fffffffc] *pgdOffe821, *pte\0000000, *ppte\0000000
Internal error: Oops: 17 [#2] PREEMPT SMP ARM
Modules linked in:
init: plymouth main process (471) killed by SEGV signal
init: plymouth-splash main process (3110) terminated with status 2
CPU: 1    Tainted: G      D       (3.6.0-rc2+ #103)
PC is at kthread_data+0x10/0x18
LR is at irq_thread_dtor+0x58/0xcc
init: Failed to create pty - disabling logging for job
init: Temporary process spawn error: No such file or directory
pc : [<c00388b4>]    lr : [<c0061500>]    psr: 20000113
sp : ce9f1cf0  ip : ce9f1d00  fp : ce9f1cfc
r10: c0264b7c  r9 : 00000008  r8 : 00000000
r7 : ce9bac38  r6 : 00000000  r5 : ce9ba9c0  r4 : ce9ba9c0
r3 : 00000000  r2 : ce9f1d00  r1 : a0000113  r0 : ce9ba9c0
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 4fb7404a  DAC: 00000015
Process irq/173-sh_mmc: (pid: 397, stack limit = 0xce9f02f0)
Stack: (0xce9f1cf0 to 0xce9f2000)
1ce0:                                     ce9f1d14 ce9f1d00 c0061500 c00388b0
1d00: ce9ba9c0 00000000 ce9f1d34 ce9f1d18 c0035a58 c00614b4 ce9ba9c0 0000000b
1d20: c0264b7e ce9f1db2 ce9f1d64 ce9f1d38 c0021b3c c0035a08 ce9f1ee8 00000001
1d40: c0264b7e 00670067 ce9f1d64 ce9f1d58 c001cd80 ce9f1db2 ce9f1de4 ce9f1d68
1d60: c0012484 c002191c ce9f02f0 0000000b c0004000 c03d8f35 60000113 00000000
1d80: 65a426f8 35313935 20343030 31383265 38333039 61316520 30303430 31652031
1da0: 30303061 28203930 35393565 38303061 c0002029 c0342444 c040ab1e 00000008
1dc0: 00000017 00000000 ce9f1ee8 00000017 cea426f8 00000028 ce9f1dfc ce9f1de8
1de0: c0342210 c00120f8 ce9f1ee8 00000000 ce9f1e3c ce9f1e00 c0015b00 c03421c0
1e00: c0046a2c c0046850 c06e2380 cea5bc80 00000005 00000017 c0461e68 00000008
1e20: ce9f1ee8 ce9f5f60 cea426f8 00000000 ce9f1ee4 ce9f1e40 c000918c c00158cc
1e40: cea5bc80 c06e2380 cea5bef8 c06e2380 ce9f1e74 ce9f1e60 c0041a48 c00417e8
1e60: cea5bc80 00000001 ce9f1ea4 ce9f1e78 c0044100 c0347008 00000000 cea45858
1e80: 00000001 cea4584c 00000001 00000003 00000000 00000000 ce9f1eb4 ce9f1ea8
1ea0: c0044128 c0043ea0 ce9f1ee4 ce9f1eb8 c004058c c0044120 00000000 cea45850
1ec0: a0000113 cea4584c c0264b7c 60000113 ffffffff ce9f1f1c ce9f1f7c ce9f1ee8
1ee0: c000e698 c000915c cea426f8 cea426c0 00000000 c0264b5c cea426c0 00000000
1f00: ce9f0000 ce9f0000 ce9f5f60 cea426f8 00000000 ce9f1f7c ce9f1f80 ce9f1f30
1f20: c0061608 c0264b7c 60000113 ffffffff c03462d0 c0040bfc cea426c0 c0455380
1f40: c0461db8 ce9f5f40 ce80ea40 ce9f0000 ce9f0000 ce9f5f40 ce80ea40 ce9f0000
1f60: ce9f0000 ce9f5f60 00000000 00000000 ce9f1fb4 ce9f1f80 c0061608 c0264b68
1f80: ce9f5f40 00000000 c00614a8 00000000 ce84bd70 ce9f5f40 c0061574 00000013
1fa0: 00000000 00000000 ce9f1ff4 ce9f1fb8 c00386c0 c0061580 00000000 00000000
1fc0: ce9f5f40 00000001 00010001 00000000 ce9f1fd0 ce9f1fd0 00000000 ce84bd70
1fe0: c003862c c0021910 00000000 ce9f1ff8 c0021910 c0038638 00000000 00000000
Backtrace:
[<c00388a4>] (kthread_data+0x0/0x18) from [<c0061500>] (irq_thread_dtor+0x58/0xcc)
[<c00614a8>] (irq_thread_dtor+0x0/0xcc) from [<c0035a58>] (task_work_run+0x5c/0x6c)
 r5:00000000 r4:ce9ba9c0
[<c00359fc>] (task_work_run+0x0/0x6c) from [<c0021b3c>] (do_exit+0x22c/0x700)
 r7:ce9f1db2 r6:c0264b7e r5:0000000b r4:ce9ba9c0
[<c0021910>] (do_exit+0x0/0x700) from [<c0012484>] (die+0x398/0x3e4)
 r7:ce9f1db2
[<c00120ec>] (die+0x0/0x3e4) from [<c0342210>] (__do_kernel_fault.part.9+0x5c/0x7c)
[<c03421b4>] (__do_kernel_fault.part.9+0x0/0x7c) from [<c0015b00>] (do_page_fault+0x240/0x258)
 r7:00000000 r3:ce9f1ee8
[<c00158c0>] (do_page_fault+0x0/0x258) from [<c000918c>] (do_DataAbort+0x3c/0xa0)
[<c0009150>] (do_DataAbort+0x0/0xa0) from [<c000e698>] (__dabt_svc+0x38/0x60)
Exception stack(0xce9f1ee8 to 0xce9f1f30)
1ee0:                   cea426f8 cea426c0 00000000 c0264b5c cea426c0 00000000
1f00: ce9f0000 ce9f0000 ce9f5f60 cea426f8 00000000 ce9f1f7c ce9f1f80 ce9f1f30
1f20: c0061608 c0264b7c 60000113 ffffffff
 r7:ce9f1f1c r6:ffffffff r5:60000113 r4:c0264b7c
[<c0264b5c>] (sh_mmcif_irqt+0x0/0xb30) from [<c0061608>] (irq_thread+0x94/0x16c)
[<c0061574>] (irq_thread+0x0/0x16c) from [<c00386c0>] (kthread+0x94/0xa0)
[<c003862c>] (kthread+0x0/0xa0) from [<c0021910>] (do_exit+0x0/0x700)
 r6:c0021910 r5:c003862c r4:ce84bd70
Code: e1a0c00d e92dd800 e24cb004 e590316c (e5130004)
---[ end trace 2f02388ade397925 ]---
Fixing recursive fault but reboot is needed!
mmcblk2: error -5 sending status command, retrying
mmcblk2: error -5 sending status command, retrying
mmcblk2: error -5 sending status command, aborting
end_request: I/O error, dev mmcblk2, sector 320
Buffer I/O error on device mmcblk2, logical block 40
mmcblk2: error -5 sending status command, retrying
mmcblk2: error -5 sending status command, retrying
mmcblk2: error -5 sending status command, aborting
  ...


My quick fix is below.

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 5d81427..e587fbc 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
 {
        struct sh_mmcif_host *host = dev_id;
        struct mmc_request *mrq = host->mrq;
-       struct mmc_data *data = mrq->data;
+       /*struct mmc_data *data = mrq->data; -- this cause null pointer access*/
+       struct mmc_data *data;
+
+       /* quick fix by koba */
+       if (mrq = NULL) {
+               printk("sh_mmcif_irqt: mrq = NULL: host->wait_for=%d\n", host->wait_for);
+       } else {
+               data = mrq->data;
+       }

        cancel_delayed_work_sync(&host->timeout_work);


With this patch, there is no null pointer accesses and got this log.

sh_mmcif_irqt: mrq = NULL: host->wait_for=0
sh_mmcif_irqt: mrq = NULL: host->wait_for=0
  ...

host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
There is code such like:

       host->wait_for = MMCIF_WAIT_FOR_REQUEST;
       host->mrq = NULL;

So, at the top of sh_mmcif_irqt, if host->wait_for = MMCIF_WAIT_FOR_REQUEST,
host->mrq = NULL. 
It is too earlier to access mrq->data before checking host->mrq. it may
cause null pointer access.

Goda-san, could you check this and refine the code of sh_mmcif_irqt?

[PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Guennadi Liakhovetski]

On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious 
interrupts without any active request. To prevent the Oops, that results 
in such cases, don't dereference the mmc request pointer until we make 
sure, that we are indeed processing such a request.

Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---

Hello Kobayashi-san

On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:

...

> After applying this patch on kzm9g board, I got this error regarding eMMC.
> I think this is another problem.
> 
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000008
> pgd = c0004000
> [00000008] *pgd\0000000
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
> PC is at sh_mmcif_irqt+0x20/0xb30
> LR is at irq_thread+0x94/0x16c

[snip]

> My quick fix is below.
> 
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 5d81427..e587fbc 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>  {
>         struct sh_mmcif_host *host = dev_id;
>         struct mmc_request *mrq = host->mrq;
> -       struct mmc_data *data = mrq->data;
> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer access*/
> +       struct mmc_data *data;
> +
> +       /* quick fix by koba */
> +       if (mrq = NULL) {
> +               printk("sh_mmcif_irqt: mrq = NULL: host->wait_for=%d\n", host->wait_for);
> +       } else {
> +               data = mrq->data;
> +       }
> 
>         cancel_delayed_work_sync(&host->timeout_work);
> 
> 
> With this patch, there is no null pointer accesses and got this log.
> 
> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>   ...
> 
> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
> There is code such like:
> 
>        host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>        host->mrq = NULL;
> 
> So, at the top of sh_mmcif_irqt, if host->wait_for = MMCIF_WAIT_FOR_REQUEST,
> host->mrq = NULL. 
> It is too earlier to access mrq->data before checking host->mrq. it may
> cause null pointer access.
> 
> Goda-san, could you check this and refine the code of sh_mmcif_irqt?

Thanks for your report and a fix. Could you please double-check, whether 
the below patch also fixes your problem? Since such spurious interrupts 
are possible I would commit a check like this one, but in the longer run 
we want to identify and eliminate them, if possible. But since so far 
these interrupts only happen on 1 board model and also not on all units 
and not upon each boot, this could be a bit tricky.

One more question - is this only needed for 3.7 or also for 3.6 / stable?

Thanks
Guennadi

 drivers/mmc/host/sh_mmcif.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 5d81427..82bf921 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
 {
 	struct sh_mmcif_host *host = dev_id;
 	struct mmc_request *mrq = host->mrq;
-	struct mmc_data *data = mrq->data;
 
 	cancel_delayed_work_sync(&host->timeout_work);
 
@@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
 	case MMCIF_WAIT_FOR_READ_END:
 	case MMCIF_WAIT_FOR_WRITE_END:
 		if (host->sd_error)
-			data->error = sh_mmcif_error_manage(host);
+			mrq->data->error = sh_mmcif_error_manage(host);
 		break;
 	default:
 		BUG();
 	}
 
 	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
+		struct mmc_data *data = mrq->data;
 		if (!mrq->cmd->error && data && !data->error)
 			data->bytes_xfered  				data->blocks * data->blksz;
-- 
1.7.2.5

[PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Guennadi Liakhovetski]

On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious 
interrupts without any active request. To prevent the Oops, that results 
in such cases, don't dereference the mmc request pointer until we make 
sure, that we are indeed processing such a request.

Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---

Hello Kobayashi-san

On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:

...

> After applying this patch on kzm9g board, I got this error regarding eMMC.
> I think this is another problem.
> 
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000008
> pgd = c0004000
> [00000008] *pgd=00000000
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
> PC is at sh_mmcif_irqt+0x20/0xb30
> LR is at irq_thread+0x94/0x16c

[snip]

> My quick fix is below.
> 
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 5d81427..e587fbc 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>  {
>         struct sh_mmcif_host *host = dev_id;
>         struct mmc_request *mrq = host->mrq;
> -       struct mmc_data *data = mrq->data;
> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer access*/
> +       struct mmc_data *data;
> +
> +       /* quick fix by koba */
> +       if (mrq == NULL) {
> +               printk("sh_mmcif_irqt: mrq == NULL: host->wait_for=%d\n", host->wait_for);
> +       } else {
> +               data = mrq->data;
> +       }
> 
>         cancel_delayed_work_sync(&host->timeout_work);
> 
> 
> With this patch, there is no null pointer accesses and got this log.
> 
> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>   ...
> 
> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
> There is code such like:
> 
>        host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>        host->mrq = NULL;
> 
> So, at the top of sh_mmcif_irqt, if host->wait_for == MMCIF_WAIT_FOR_REQUEST,
> host->mrq = NULL. 
> It is too earlier to access mrq->data before checking host->mrq. it may
> cause null pointer access.
> 
> Goda-san, could you check this and refine the code of sh_mmcif_irqt?

Thanks for your report and a fix. Could you please double-check, whether 
the below patch also fixes your problem? Since such spurious interrupts 
are possible I would commit a check like this one, but in the longer run 
we want to identify and eliminate them, if possible. But since so far 
these interrupts only happen on 1 board model and also not on all units 
and not upon each boot, this could be a bit tricky.

One more question - is this only needed for 3.7 or also for 3.6 / stable?

Thanks
Guennadi

 drivers/mmc/host/sh_mmcif.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 5d81427..82bf921 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
 {
 	struct sh_mmcif_host *host = dev_id;
 	struct mmc_request *mrq = host->mrq;
-	struct mmc_data *data = mrq->data;
 
 	cancel_delayed_work_sync(&host->timeout_work);
 
@@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
 	case MMCIF_WAIT_FOR_READ_END:
 	case MMCIF_WAIT_FOR_WRITE_END:
 		if (host->sd_error)
-			data->error = sh_mmcif_error_manage(host);
+			mrq->data->error = sh_mmcif_error_manage(host);
 		break;
 	default:
 		BUG();
 	}
 
 	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
+		struct mmc_data *data = mrq->data;
 		if (!mrq->cmd->error && data && !data->error)
 			data->bytes_xfered =
 				data->blocks * data->blksz;
-- 
1.7.2.5

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi,

Thank you for your patch. I will test this next week.

 > One more question - is this only needed for 3.7 or also for 3.6 / stable?

I hope this also for 3.6 / stable because it is more robust.
The other hand, we need investigate why this strange interrupt happens.

(2012/08/22 15:49), Guennadi Liakhovetski wrote:
> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> interrupts without any active request. To prevent the Oops, that results
> in such cases, don't dereference the mmc request pointer until we make
> sure, that we are indeed processing such a request.
>
> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>
> Hello Kobayashi-san
>
> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>
> ...
>
>> After applying this patch on kzm9g board, I got this error regarding eMMC.
>> I think this is another problem.
>>
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 00000008
>> pgd = c0004000
>> [00000008] *pgd\0000000
>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> Modules linked in:
>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>> PC is at sh_mmcif_irqt+0x20/0xb30
>> LR is at irq_thread+0x94/0x16c
>
> [snip]
>
>> My quick fix is below.
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..e587fbc 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   {
>>          struct sh_mmcif_host *host = dev_id;
>>          struct mmc_request *mrq = host->mrq;
>> -       struct mmc_data *data = mrq->data;
>> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer access*/
>> +       struct mmc_data *data;
>> +
>> +       /* quick fix by koba */
>> +       if (mrq = NULL) {
>> +               printk("sh_mmcif_irqt: mrq = NULL: host->wait_for=%d\n", host->wait_for);
>> +       } else {
>> +               data = mrq->data;
>> +       }
>>
>>          cancel_delayed_work_sync(&host->timeout_work);
>>
>>
>> With this patch, there is no null pointer accesses and got this log.
>>
>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>>    ...
>>
>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>> There is code such like:
>>
>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>         host->mrq = NULL;
>>
>> So, at the top of sh_mmcif_irqt, if host->wait_for = MMCIF_WAIT_FOR_REQUEST,
>> host->mrq = NULL.
>> It is too earlier to access mrq->data before checking host->mrq. it may
>> cause null pointer access.
>>
>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>
> Thanks for your report and a fix. Could you please double-check, whether
> the below patch also fixes your problem? Since such spurious interrupts
> are possible I would commit a check like this one, but in the longer run
> we want to identify and eliminate them, if possible. But since so far
> these interrupts only happen on 1 board model and also not on all units
> and not upon each boot, this could be a bit tricky.
>
> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>
> Thanks
> Guennadi
>
>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 5d81427..82bf921 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   {
>   	struct sh_mmcif_host *host = dev_id;
>   	struct mmc_request *mrq = host->mrq;
> -	struct mmc_data *data = mrq->data;
>
>   	cancel_delayed_work_sync(&host->timeout_work);
>
> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   	case MMCIF_WAIT_FOR_READ_END:
>   	case MMCIF_WAIT_FOR_WRITE_END:
>   		if (host->sd_error)
> -			data->error = sh_mmcif_error_manage(host);
> +			mrq->data->error = sh_mmcif_error_manage(host);
>   		break;
>   	default:
>   		BUG();
>   	}
>
>   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> +		struct mmc_data *data = mrq->data;
>   		if (!mrq->cmd->error && data && !data->error)
>   			data->bytes_xfered >   				data->blocks * data->blksz;
>

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi,

Thank you for your patch. I will test this next week.

 > One more question - is this only needed for 3.7 or also for 3.6 / stable?

I hope this also for 3.6 / stable because it is more robust.
The other hand, we need investigate why this strange interrupt happens.

(2012/08/22 15:49), Guennadi Liakhovetski wrote:
> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> interrupts without any active request. To prevent the Oops, that results
> in such cases, don't dereference the mmc request pointer until we make
> sure, that we are indeed processing such a request.
>
> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>
> Hello Kobayashi-san
>
> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>
> ...
>
>> After applying this patch on kzm9g board, I got this error regarding eMMC.
>> I think this is another problem.
>>
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 00000008
>> pgd = c0004000
>> [00000008] *pgd=00000000
>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> Modules linked in:
>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>> PC is at sh_mmcif_irqt+0x20/0xb30
>> LR is at irq_thread+0x94/0x16c
>
> [snip]
>
>> My quick fix is below.
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..e587fbc 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   {
>>          struct sh_mmcif_host *host = dev_id;
>>          struct mmc_request *mrq = host->mrq;
>> -       struct mmc_data *data = mrq->data;
>> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer access*/
>> +       struct mmc_data *data;
>> +
>> +       /* quick fix by koba */
>> +       if (mrq == NULL) {
>> +               printk("sh_mmcif_irqt: mrq == NULL: host->wait_for=%d\n", host->wait_for);
>> +       } else {
>> +               data = mrq->data;
>> +       }
>>
>>          cancel_delayed_work_sync(&host->timeout_work);
>>
>>
>> With this patch, there is no null pointer accesses and got this log.
>>
>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>    ...
>>
>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>> There is code such like:
>>
>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>         host->mrq = NULL;
>>
>> So, at the top of sh_mmcif_irqt, if host->wait_for == MMCIF_WAIT_FOR_REQUEST,
>> host->mrq = NULL.
>> It is too earlier to access mrq->data before checking host->mrq. it may
>> cause null pointer access.
>>
>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>
> Thanks for your report and a fix. Could you please double-check, whether
> the below patch also fixes your problem? Since such spurious interrupts
> are possible I would commit a check like this one, but in the longer run
> we want to identify and eliminate them, if possible. But since so far
> these interrupts only happen on 1 board model and also not on all units
> and not upon each boot, this could be a bit tricky.
>
> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>
> Thanks
> Guennadi
>
>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 5d81427..82bf921 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   {
>   	struct sh_mmcif_host *host = dev_id;
>   	struct mmc_request *mrq = host->mrq;
> -	struct mmc_data *data = mrq->data;
>
>   	cancel_delayed_work_sync(&host->timeout_work);
>
> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   	case MMCIF_WAIT_FOR_READ_END:
>   	case MMCIF_WAIT_FOR_WRITE_END:
>   		if (host->sd_error)
> -			data->error = sh_mmcif_error_manage(host);
> +			mrq->data->error = sh_mmcif_error_manage(host);
>   		break;
>   	default:
>   		BUG();
>   	}
>
>   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> +		struct mmc_data *data = mrq->data;
>   		if (!mrq->cmd->error && data && !data->error)
>   			data->bytes_xfered =
>   				data->blocks * data->blksz;
>

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Guennadi Liakhovetski]

Hello Kobayashi-san

On Wed, 22 Aug 2012, Tetsuyuki Kobayashi wrote:

> Hello Guennadi,
> 
> Thank you for your patch. I will test this next week.

Great, thanks very much! I'l also try to fund some time early in September 
to test on my board. Could you please send me your .config kernel 
configuration (off-list)?

Thanks
Guennadi

> > One more question - is this only needed for 3.7 or also for 3.6 / stable?
> 
> I hope this also for 3.6 / stable because it is more robust.
> The other hand, we need investigate why this strange interrupt happens.
> 
> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
> > On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> > interrupts without any active request. To prevent the Oops, that results
> > in such cases, don't dereference the mmc request pointer until we make
> > sure, that we are indeed processing such a request.
> > 
> > Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> > 
> > Hello Kobayashi-san
> > 
> > On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
> > 
> > ...
> > 
> > > After applying this patch on kzm9g board, I got this error regarding eMMC.
> > > I think this is another problem.
> > > 
> > > 
> > > Unable to handle kernel NULL pointer dereference at virtual address
> > > 00000008
> > > pgd = c0004000
> > > [00000008] *pgd\0000000
> > > Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> > > Modules linked in:
> > > CPU: 1    Not tainted  (3.6.0-rc2+ #103)
> > > PC is at sh_mmcif_irqt+0x20/0xb30
> > > LR is at irq_thread+0x94/0x16c
> > 
> > [snip]
> > 
> > > My quick fix is below.
> > > 
> > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > index 5d81427..e587fbc 100644
> > > --- a/drivers/mmc/host/sh_mmcif.c
> > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > *dev_id)
> > >   {
> > >          struct sh_mmcif_host *host = dev_id;
> > >          struct mmc_request *mrq = host->mrq;
> > > -       struct mmc_data *data = mrq->data;
> > > +       /*struct mmc_data *data = mrq->data; -- this cause null pointer
> > > access*/
> > > +       struct mmc_data *data;
> > > +
> > > +       /* quick fix by koba */
> > > +       if (mrq = NULL) {
> > > +               printk("sh_mmcif_irqt: mrq = NULL: host->wait_for=%d\n",
> > > host->wait_for);
> > > +       } else {
> > > +               data = mrq->data;
> > > +       }
> > > 
> > >          cancel_delayed_work_sync(&host->timeout_work);
> > > 
> > > 
> > > With this patch, there is no null pointer accesses and got this log.
> > > 
> > > sh_mmcif_irqt: mrq = NULL: host->wait_for=0
> > > sh_mmcif_irqt: mrq = NULL: host->wait_for=0
> > >    ...
> > > 
> > > host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
> > > There is code such like:
> > > 
> > >         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
> > >         host->mrq = NULL;
> > > 
> > > So, at the top of sh_mmcif_irqt, if host->wait_for =
> > > MMCIF_WAIT_FOR_REQUEST,
> > > host->mrq = NULL.
> > > It is too earlier to access mrq->data before checking host->mrq. it may
> > > cause null pointer access.
> > > 
> > > Goda-san, could you check this and refine the code of sh_mmcif_irqt?
> > 
> > Thanks for your report and a fix. Could you please double-check, whether
> > the below patch also fixes your problem? Since such spurious interrupts
> > are possible I would commit a check like this one, but in the longer run
> > we want to identify and eliminate them, if possible. But since so far
> > these interrupts only happen on 1 board model and also not on all units
> > and not upon each boot, this could be a bit tricky.
> > 
> > One more question - is this only needed for 3.7 or also for 3.6 / stable?
> > 
> > Thanks
> > Guennadi
> > 
> >   drivers/mmc/host/sh_mmcif.c |    4 ++--
> >   1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > index 5d81427..82bf921 100644
> > --- a/drivers/mmc/host/sh_mmcif.c
> > +++ b/drivers/mmc/host/sh_mmcif.c
> > @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > *dev_id)
> >   {
> >   	struct sh_mmcif_host *host = dev_id;
> >   	struct mmc_request *mrq = host->mrq;
> > -	struct mmc_data *data = mrq->data;
> > 
> >   	cancel_delayed_work_sync(&host->timeout_work);
> > 
> > @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > *dev_id)
> >   	case MMCIF_WAIT_FOR_READ_END:
> >   	case MMCIF_WAIT_FOR_WRITE_END:
> >   		if (host->sd_error)
> > -			data->error = sh_mmcif_error_manage(host);
> > +			mrq->data->error = sh_mmcif_error_manage(host);
> >   		break;
> >   	default:
> >   		BUG();
> >   	}
> > 
> >   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> > +		struct mmc_data *data = mrq->data;
> >   		if (!mrq->cmd->error && data && !data->error)
> >   			data->bytes_xfered > >   				data->blocks * data->blksz;
> > 
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Guennadi Liakhovetski]

Hello Kobayashi-san

On Wed, 22 Aug 2012, Tetsuyuki Kobayashi wrote:

> Hello Guennadi,
> 
> Thank you for your patch. I will test this next week.

Great, thanks very much! I'l also try to fund some time early in September 
to test on my board. Could you please send me your .config kernel 
configuration (off-list)?

Thanks
Guennadi

> > One more question - is this only needed for 3.7 or also for 3.6 / stable?
> 
> I hope this also for 3.6 / stable because it is more robust.
> The other hand, we need investigate why this strange interrupt happens.
> 
> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
> > On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> > interrupts without any active request. To prevent the Oops, that results
> > in such cases, don't dereference the mmc request pointer until we make
> > sure, that we are indeed processing such a request.
> > 
> > Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> > 
> > Hello Kobayashi-san
> > 
> > On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
> > 
> > ...
> > 
> > > After applying this patch on kzm9g board, I got this error regarding eMMC.
> > > I think this is another problem.
> > > 
> > > 
> > > Unable to handle kernel NULL pointer dereference at virtual address
> > > 00000008
> > > pgd = c0004000
> > > [00000008] *pgd=00000000
> > > Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> > > Modules linked in:
> > > CPU: 1    Not tainted  (3.6.0-rc2+ #103)
> > > PC is at sh_mmcif_irqt+0x20/0xb30
> > > LR is at irq_thread+0x94/0x16c
> > 
> > [snip]
> > 
> > > My quick fix is below.
> > > 
> > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > index 5d81427..e587fbc 100644
> > > --- a/drivers/mmc/host/sh_mmcif.c
> > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > *dev_id)
> > >   {
> > >          struct sh_mmcif_host *host = dev_id;
> > >          struct mmc_request *mrq = host->mrq;
> > > -       struct mmc_data *data = mrq->data;
> > > +       /*struct mmc_data *data = mrq->data; -- this cause null pointer
> > > access*/
> > > +       struct mmc_data *data;
> > > +
> > > +       /* quick fix by koba */
> > > +       if (mrq == NULL) {
> > > +               printk("sh_mmcif_irqt: mrq == NULL: host->wait_for=%d\n",
> > > host->wait_for);
> > > +       } else {
> > > +               data = mrq->data;
> > > +       }
> > > 
> > >          cancel_delayed_work_sync(&host->timeout_work);
> > > 
> > > 
> > > With this patch, there is no null pointer accesses and got this log.
> > > 
> > > sh_mmcif_irqt: mrq == NULL: host->wait_for=0
> > > sh_mmcif_irqt: mrq == NULL: host->wait_for=0
> > >    ...
> > > 
> > > host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
> > > There is code such like:
> > > 
> > >         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
> > >         host->mrq = NULL;
> > > 
> > > So, at the top of sh_mmcif_irqt, if host->wait_for ==
> > > MMCIF_WAIT_FOR_REQUEST,
> > > host->mrq = NULL.
> > > It is too earlier to access mrq->data before checking host->mrq. it may
> > > cause null pointer access.
> > > 
> > > Goda-san, could you check this and refine the code of sh_mmcif_irqt?
> > 
> > Thanks for your report and a fix. Could you please double-check, whether
> > the below patch also fixes your problem? Since such spurious interrupts
> > are possible I would commit a check like this one, but in the longer run
> > we want to identify and eliminate them, if possible. But since so far
> > these interrupts only happen on 1 board model and also not on all units
> > and not upon each boot, this could be a bit tricky.
> > 
> > One more question - is this only needed for 3.7 or also for 3.6 / stable?
> > 
> > Thanks
> > Guennadi
> > 
> >   drivers/mmc/host/sh_mmcif.c |    4 ++--
> >   1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > index 5d81427..82bf921 100644
> > --- a/drivers/mmc/host/sh_mmcif.c
> > +++ b/drivers/mmc/host/sh_mmcif.c
> > @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > *dev_id)
> >   {
> >   	struct sh_mmcif_host *host = dev_id;
> >   	struct mmc_request *mrq = host->mrq;
> > -	struct mmc_data *data = mrq->data;
> > 
> >   	cancel_delayed_work_sync(&host->timeout_work);
> > 
> > @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > *dev_id)
> >   	case MMCIF_WAIT_FOR_READ_END:
> >   	case MMCIF_WAIT_FOR_WRITE_END:
> >   		if (host->sd_error)
> > -			data->error = sh_mmcif_error_manage(host);
> > +			mrq->data->error = sh_mmcif_error_manage(host);
> >   		break;
> >   	default:
> >   		BUG();
> >   	}
> > 
> >   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> > +		struct mmc_data *data = mrq->data;
> >   		if (!mrq->cmd->error && data && !data->error)
> >   			data->bytes_xfered =
> >   				data->blocks * data->blksz;
> > 
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

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

Hello Guennadi,

(2012/08/23 16:11), Guennadi Liakhovetski wrote:> Hello Kobayashi-san
 >
 > On Wed, 22 Aug 2012, Tetsuyuki Kobayashi wrote:
 >
 >> Hello Guennadi,
 >>
 >> Thank you for your patch. I will test this next week.
 >
 > Great, thanks very much! I'l also try to fund some time early in 
September
 > to test on my board. Could you please send me your .config kernel
 > configuration (off-list)?

I attached my .config file for kzm9g board.

My working source tree is:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
checkout kzm9g branch

apply these 3 patches:

[PATCH] ARM: mach-shmobile: Add compilation support for dtbs using 'make 
dtbs'
http://www.spinics.net/lists/linux-sh/msg12970.html

Paul's irqdomain patch
http://www.spinics.net/lists/linux-sh/msg12760.html

[PATCH] ARM: shmobile: sh73a0: fixup RELOC_BASE of intca_irq_pins_desc
http://www.spinics.net/lists/linux-sh/msg12876.html

and then, apply your patch for sh_mmcif.c

Simon's Booting DT kernel on a non-DT bootloader is helpful, too.
http://www.spinics.net/lists/linux-sh/msg13051.html

I made 1 partition of eMMC by fdisk command and made ext4 file system on it.
The spurious interrupts occurs at boot time and when accesses file sytem
on eMMC.


>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>>> interrupts without any active request. To prevent the Oops, that results
>>> in such cases, don't dereference the mmc request pointer until we make
>>> sure, that we are indeed processing such a request.
>>>
>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>>> ---
>>>
>>> Hello Kobayashi-san
>>>
>>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>>>
>>> ...
>>>
>>>> After applying this patch on kzm9g board, I got this error regarding eMMC.
>>>> I think this is another problem.
>>>>
>>>>
>>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>> 00000008
>>>> pgd = c0004000
>>>> [00000008] *pgd=00000000
>>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>>>> Modules linked in:
>>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>>>> PC is at sh_mmcif_irqt+0x20/0xb30
>>>> LR is at irq_thread+0x94/0x16c
>>>
>>> [snip]
>>>
>>>> My quick fix is below.
>>>>
>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>> index 5d81427..e587fbc 100644
>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>> *dev_id)
>>>>    {
>>>>           struct sh_mmcif_host *host = dev_id;
>>>>           struct mmc_request *mrq = host->mrq;
>>>> -       struct mmc_data *data = mrq->data;
>>>> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer
>>>> access*/
>>>> +       struct mmc_data *data;
>>>> +
>>>> +       /* quick fix by koba */
>>>> +       if (mrq == NULL) {
>>>> +               printk("sh_mmcif_irqt: mrq == NULL: host->wait_for=%d\n",
>>>> host->wait_for);
>>>> +       } else {
>>>> +               data = mrq->data;
>>>> +       }
>>>>
>>>>           cancel_delayed_work_sync(&host->timeout_work);
>>>>
>>>>
>>>> With this patch, there is no null pointer accesses and got this log.
>>>>
>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>>>     ...
>>>>
>>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>>>> There is code such like:
>>>>
>>>>          host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>>>          host->mrq = NULL;
>>>>
>>>> So, at the top of sh_mmcif_irqt, if host->wait_for ==
>>>> MMCIF_WAIT_FOR_REQUEST,
>>>> host->mrq = NULL.
>>>> It is too earlier to access mrq->data before checking host->mrq. it may
>>>> cause null pointer access.
>>>>
>>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>>>
>>> Thanks for your report and a fix. Could you please double-check, whether
>>> the below patch also fixes your problem? Since such spurious interrupts
>>> are possible I would commit a check like this one, but in the longer run
>>> we want to identify and eliminate them, if possible. But since so far
>>> these interrupts only happen on 1 board model and also not on all units
>>> and not upon each boot, this could be a bit tricky.
>>>
>>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>>>
>>> Thanks
>>> Guennadi
>>>
>>>    drivers/mmc/host/sh_mmcif.c |    4 ++--
>>>    1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>> index 5d81427..82bf921 100644
>>> --- a/drivers/mmc/host/sh_mmcif.c
>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>> *dev_id)
>>>    {
>>>    	struct sh_mmcif_host *host = dev_id;
>>>    	struct mmc_request *mrq = host->mrq;
>>> -	struct mmc_data *data = mrq->data;
>>>
>>>    	cancel_delayed_work_sync(&host->timeout_work);
>>>
>>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>> *dev_id)
>>>    	case MMCIF_WAIT_FOR_READ_END:
>>>    	case MMCIF_WAIT_FOR_WRITE_END:
>>>    		if (host->sd_error)
>>> -			data->error = sh_mmcif_error_manage(host);
>>> +			mrq->data->error = sh_mmcif_error_manage(host);
>>>    		break;
>>>    	default:
>>>    		BUG();
>>>    	}
>>>
>>>    	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>>> +		struct mmc_data *data = mrq->data;
>>>    		if (!mrq->cmd->error && data && !data->error)
>>>    			data->bytes_xfered =
>>>    				data->blocks * data->blksz;
>>>



[-- Attachment #2: kzm9g_koba_defconfig --]
[-- Type: text/plain, Size: 3783 bytes --]

# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_EMBEDDED=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_ARCH_SHMOBILE=y
CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_ARCH_SH73A0=y
CONFIG_MACH_KZM9G=y
CONFIG_MEMORY_START=0x41000000
CONFIG_MEMORY_SIZE=0x1f000000
CONFIG_PL310_ERRATA_588369=y
CONFIG_PL310_ERRATA_727915=y
CONFIG_ARM_ERRATA_743622=y
CONFIG_ARM_ERRATA_751472=y
CONFIG_ARM_ERRATA_754322=y
CONFIG_ARM_ERRATA_754327=y
CONFIG_ARM_ERRATA_764369=y
CONFIG_PL310_ERRATA_769419=y
CONFIG_SMP=y
CONFIG_SCHED_MC=y
CONFIG_PREEMPT=y
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_HIGHMEM=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_CMDLINE="console=tty0 console=ttySC4,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rw ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200"
CONFIG_CMDLINE_FORCE=y
CONFIG_KEXEC=y
CONFIG_VFP=y
CONFIG_NEON=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_PM_RUNTIME=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_IPV6 is not set
CONFIG_IRDA=y
CONFIG_SH_IRDA=y
# CONFIG_WIRELESS is not set
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_NETDEVICES=y
CONFIG_SMSC911X=y
# CONFIG_WLAN is not set
CONFIG_INPUT_SPARSEKMAP=y
# CONFIG_INPUT_MOUSEDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_KEYBOARD_ATKBD is not set
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ST1232=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=9
CONFIG_SERIAL_SH_SCI_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_SH_MOBILE=y
CONFIG_GPIO_PCF857X=y
# CONFIG_HWMON is not set
CONFIG_FB=y
CONFIG_FB_SH_MOBILE_LCDC=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
CONFIG_FB_SH_MOBILE_MERAM=y
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_DRIVERS is not set
# CONFIG_SND_ARM is not set
# CONFIG_SND_USB is not set
CONFIG_SND_SOC=y
CONFIG_SND_SOC_SH4_FSI=y
CONFIG_USB=y
CONFIG_USB_R8A66597_HCD=y
CONFIG_USB_RENESAS_USBHS=y
CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=y
CONFIG_USB_RENESAS_USBHS_UDC=y
CONFIG_USB_ETH=m
CONFIG_USB_MASS_STORAGE=m
CONFIG_MMC=y
# CONFIG_MMC_BLOCK_BOUNCE is not set
CONFIG_MMC_SDHI=y
CONFIG_MMC_SH_MMCIF=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_RS5C372=y
CONFIG_DMADEVICES=y
CONFIG_SH_DMAE=y
CONFIG_ASYNC_TX_DMA=y
CONFIG_STAGING=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_ROOT_NFS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_FTRACE is not set
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_DES=y

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

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

Hello Guennadi,

(2012/08/23 16:11), Guennadi Liakhovetski wrote:> Hello Kobayashi-san
 >
 > On Wed, 22 Aug 2012, Tetsuyuki Kobayashi wrote:
 >
 >> Hello Guennadi,
 >>
 >> Thank you for your patch. I will test this next week.
 >
 > Great, thanks very much! I'l also try to fund some time early in 
September
 > to test on my board. Could you please send me your .config kernel
 > configuration (off-list)?

I attached my .config file for kzm9g board.

My working source tree is:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
checkout kzm9g branch

apply these 3 patches:

[PATCH] ARM: mach-shmobile: Add compilation support for dtbs using 'make 
dtbs'
http://www.spinics.net/lists/linux-sh/msg12970.html

Paul's irqdomain patch
http://www.spinics.net/lists/linux-sh/msg12760.html

[PATCH] ARM: shmobile: sh73a0: fixup RELOC_BASE of intca_irq_pins_desc
http://www.spinics.net/lists/linux-sh/msg12876.html

and then, apply your patch for sh_mmcif.c

Simon's Booting DT kernel on a non-DT bootloader is helpful, too.
http://www.spinics.net/lists/linux-sh/msg13051.html

I made 1 partition of eMMC by fdisk command and made ext4 file system on it.
The spurious interrupts occurs at boot time and when accesses file sytem
on eMMC.


>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>>> interrupts without any active request. To prevent the Oops, that results
>>> in such cases, don't dereference the mmc request pointer until we make
>>> sure, that we are indeed processing such a request.
>>>
>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>>> ---
>>>
>>> Hello Kobayashi-san
>>>
>>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>>>
>>> ...
>>>
>>>> After applying this patch on kzm9g board, I got this error regarding eMMC.
>>>> I think this is another problem.
>>>>
>>>>
>>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>> 00000008
>>>> pgd = c0004000
>>>> [00000008] *pgd=00000000
>>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>>>> Modules linked in:
>>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>>>> PC is at sh_mmcif_irqt+0x20/0xb30
>>>> LR is at irq_thread+0x94/0x16c
>>>
>>> [snip]
>>>
>>>> My quick fix is below.
>>>>
>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>> index 5d81427..e587fbc 100644
>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>> *dev_id)
>>>>    {
>>>>           struct sh_mmcif_host *host = dev_id;
>>>>           struct mmc_request *mrq = host->mrq;
>>>> -       struct mmc_data *data = mrq->data;
>>>> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer
>>>> access*/
>>>> +       struct mmc_data *data;
>>>> +
>>>> +       /* quick fix by koba */
>>>> +       if (mrq == NULL) {
>>>> +               printk("sh_mmcif_irqt: mrq == NULL: host->wait_for=%d\n",
>>>> host->wait_for);
>>>> +       } else {
>>>> +               data = mrq->data;
>>>> +       }
>>>>
>>>>           cancel_delayed_work_sync(&host->timeout_work);
>>>>
>>>>
>>>> With this patch, there is no null pointer accesses and got this log.
>>>>
>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>>>     ...
>>>>
>>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>>>> There is code such like:
>>>>
>>>>          host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>>>          host->mrq = NULL;
>>>>
>>>> So, at the top of sh_mmcif_irqt, if host->wait_for ==
>>>> MMCIF_WAIT_FOR_REQUEST,
>>>> host->mrq = NULL.
>>>> It is too earlier to access mrq->data before checking host->mrq. it may
>>>> cause null pointer access.
>>>>
>>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>>>
>>> Thanks for your report and a fix. Could you please double-check, whether
>>> the below patch also fixes your problem? Since such spurious interrupts
>>> are possible I would commit a check like this one, but in the longer run
>>> we want to identify and eliminate them, if possible. But since so far
>>> these interrupts only happen on 1 board model and also not on all units
>>> and not upon each boot, this could be a bit tricky.
>>>
>>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>>>
>>> Thanks
>>> Guennadi
>>>
>>>    drivers/mmc/host/sh_mmcif.c |    4 ++--
>>>    1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>> index 5d81427..82bf921 100644
>>> --- a/drivers/mmc/host/sh_mmcif.c
>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>> *dev_id)
>>>    {
>>>    	struct sh_mmcif_host *host = dev_id;
>>>    	struct mmc_request *mrq = host->mrq;
>>> -	struct mmc_data *data = mrq->data;
>>>
>>>    	cancel_delayed_work_sync(&host->timeout_work);
>>>
>>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>> *dev_id)
>>>    	case MMCIF_WAIT_FOR_READ_END:
>>>    	case MMCIF_WAIT_FOR_WRITE_END:
>>>    		if (host->sd_error)
>>> -			data->error = sh_mmcif_error_manage(host);
>>> +			mrq->data->error = sh_mmcif_error_manage(host);
>>>    		break;
>>>    	default:
>>>    		BUG();
>>>    	}
>>>
>>>    	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>>> +		struct mmc_data *data = mrq->data;
>>>    		if (!mrq->cmd->error && data && !data->error)
>>>    			data->bytes_xfered =
>>>    				data->blocks * data->blksz;
>>>



[-- Attachment #2: kzm9g_koba_defconfig --]
[-- Type: text/plain, Size: 3783 bytes --]

# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_EMBEDDED=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_ARCH_SHMOBILE=y
CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_ARCH_SH73A0=y
CONFIG_MACH_KZM9G=y
CONFIG_MEMORY_START=0x41000000
CONFIG_MEMORY_SIZE=0x1f000000
CONFIG_PL310_ERRATA_588369=y
CONFIG_PL310_ERRATA_727915=y
CONFIG_ARM_ERRATA_743622=y
CONFIG_ARM_ERRATA_751472=y
CONFIG_ARM_ERRATA_754322=y
CONFIG_ARM_ERRATA_754327=y
CONFIG_ARM_ERRATA_764369=y
CONFIG_PL310_ERRATA_769419=y
CONFIG_SMP=y
CONFIG_SCHED_MC=y
CONFIG_PREEMPT=y
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_HIGHMEM=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_CMDLINE="console=tty0 console=ttySC4,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rw ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200"
CONFIG_CMDLINE_FORCE=y
CONFIG_KEXEC=y
CONFIG_VFP=y
CONFIG_NEON=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_PM_RUNTIME=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_IPV6 is not set
CONFIG_IRDA=y
CONFIG_SH_IRDA=y
# CONFIG_WIRELESS is not set
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_NETDEVICES=y
CONFIG_SMSC911X=y
# CONFIG_WLAN is not set
CONFIG_INPUT_SPARSEKMAP=y
# CONFIG_INPUT_MOUSEDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_KEYBOARD_ATKBD is not set
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ST1232=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=9
CONFIG_SERIAL_SH_SCI_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_SH_MOBILE=y
CONFIG_GPIO_PCF857X=y
# CONFIG_HWMON is not set
CONFIG_FB=y
CONFIG_FB_SH_MOBILE_LCDC=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
CONFIG_FB_SH_MOBILE_MERAM=y
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_DRIVERS is not set
# CONFIG_SND_ARM is not set
# CONFIG_SND_USB is not set
CONFIG_SND_SOC=y
CONFIG_SND_SOC_SH4_FSI=y
CONFIG_USB=y
CONFIG_USB_R8A66597_HCD=y
CONFIG_USB_RENESAS_USBHS=y
CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=y
CONFIG_USB_RENESAS_USBHS_UDC=y
CONFIG_USB_ETH=m
CONFIG_USB_MASS_STORAGE=m
CONFIG_MMC=y
# CONFIG_MMC_BLOCK_BOUNCE is not set
CONFIG_MMC_SDHI=y
CONFIG_MMC_SH_MMCIF=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_RS5C372=y
CONFIG_DMADEVICES=y
CONFIG_SH_DMAE=y
CONFIG_ASYNC_TX_DMA=y
CONFIG_STAGING=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_ROOT_NFS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_FTRACE is not set
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_DES=y

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi

(2012/08/22 15:49), Guennadi Liakhovetski wrote:
> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> interrupts without any active request. To prevent the Oops, that results
> in such cases, don't dereference the mmc request pointer until we make
> sure, that we are indeed processing such a request.
>
> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>
> Hello Kobayashi-san
>
> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>
> ...
>
>> After applying this patch on kzm9g board, I got this error regarding eMMC.
>> I think this is another problem.
>>
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 00000008
>> pgd = c0004000
>> [00000008] *pgd\0000000
>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> Modules linked in:
>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>> PC is at sh_mmcif_irqt+0x20/0xb30
>> LR is at irq_thread+0x94/0x16c
>
> [snip]
>
>> My quick fix is below.
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..e587fbc 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   {
>>          struct sh_mmcif_host *host = dev_id;
>>          struct mmc_request *mrq = host->mrq;
>> -       struct mmc_data *data = mrq->data;
>> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer access*/
>> +       struct mmc_data *data;
>> +
>> +       /* quick fix by koba */
>> +       if (mrq = NULL) {
>> +               printk("sh_mmcif_irqt: mrq = NULL: host->wait_for=%d\n", host->wait_for);
>> +       } else {
>> +               data = mrq->data;
>> +       }
>>
>>          cancel_delayed_work_sync(&host->timeout_work);
>>
>>
>> With this patch, there is no null pointer accesses and got this log.
>>
>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>>    ...
>>
>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>> There is code such like:
>>
>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>         host->mrq = NULL;
>>
>> So, at the top of sh_mmcif_irqt, if host->wait_for = MMCIF_WAIT_FOR_REQUEST,
>> host->mrq = NULL.
>> It is too earlier to access mrq->data before checking host->mrq. it may
>> cause null pointer access.
>>
>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>
> Thanks for your report and a fix. Could you please double-check, whether
> the below patch also fixes your problem? Since such spurious interrupts
> are possible I would commit a check like this one, but in the longer run
> we want to identify and eliminate them, if possible. But since so far
> these interrupts only happen on 1 board model and also not on all units
> and not upon each boot, this could be a bit tricky.
>
> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>
> Thanks
> Guennadi
>
>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 5d81427..82bf921 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   {
>   	struct sh_mmcif_host *host = dev_id;
>   	struct mmc_request *mrq = host->mrq;
> -	struct mmc_data *data = mrq->data;
>
>   	cancel_delayed_work_sync(&host->timeout_work);
>
> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   	case MMCIF_WAIT_FOR_READ_END:
>   	case MMCIF_WAIT_FOR_WRITE_END:
>   		if (host->sd_error)
> -			data->error = sh_mmcif_error_manage(host);
> +			mrq->data->error = sh_mmcif_error_manage(host);
>   		break;
>   	default:
>   		BUG();
>   	}
>
>   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> +		struct mmc_data *data = mrq->data;
>   		if (!mrq->cmd->error && data && !data->error)
>   			data->bytes_xfered >   				data->blocks * data->blksz;
>

I tried this patch. It seems better.
But I think this still have potential race condition.
I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to 
host->wait_for for new request at the same time.
How about add this code at the top of sh_mmcif_irqt or before returning 
IRQ_WAKE_THREAD in sh_mmcif_intr ?

	if (host->state = STATE_IDLE)
		return IRQ_HANDLED;

I will rebase my test environment to v3.6-rc3 or later. Then I will
send you my .config.

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi

(2012/08/22 15:49), Guennadi Liakhovetski wrote:
> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> interrupts without any active request. To prevent the Oops, that results
> in such cases, don't dereference the mmc request pointer until we make
> sure, that we are indeed processing such a request.
>
> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>
> Hello Kobayashi-san
>
> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>
> ...
>
>> After applying this patch on kzm9g board, I got this error regarding eMMC.
>> I think this is another problem.
>>
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 00000008
>> pgd = c0004000
>> [00000008] *pgd=00000000
>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> Modules linked in:
>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>> PC is at sh_mmcif_irqt+0x20/0xb30
>> LR is at irq_thread+0x94/0x16c
>
> [snip]
>
>> My quick fix is below.
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..e587fbc 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   {
>>          struct sh_mmcif_host *host = dev_id;
>>          struct mmc_request *mrq = host->mrq;
>> -       struct mmc_data *data = mrq->data;
>> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer access*/
>> +       struct mmc_data *data;
>> +
>> +       /* quick fix by koba */
>> +       if (mrq == NULL) {
>> +               printk("sh_mmcif_irqt: mrq == NULL: host->wait_for=%d\n", host->wait_for);
>> +       } else {
>> +               data = mrq->data;
>> +       }
>>
>>          cancel_delayed_work_sync(&host->timeout_work);
>>
>>
>> With this patch, there is no null pointer accesses and got this log.
>>
>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>    ...
>>
>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>> There is code such like:
>>
>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>         host->mrq = NULL;
>>
>> So, at the top of sh_mmcif_irqt, if host->wait_for == MMCIF_WAIT_FOR_REQUEST,
>> host->mrq = NULL.
>> It is too earlier to access mrq->data before checking host->mrq. it may
>> cause null pointer access.
>>
>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>
> Thanks for your report and a fix. Could you please double-check, whether
> the below patch also fixes your problem? Since such spurious interrupts
> are possible I would commit a check like this one, but in the longer run
> we want to identify and eliminate them, if possible. But since so far
> these interrupts only happen on 1 board model and also not on all units
> and not upon each boot, this could be a bit tricky.
>
> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>
> Thanks
> Guennadi
>
>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 5d81427..82bf921 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   {
>   	struct sh_mmcif_host *host = dev_id;
>   	struct mmc_request *mrq = host->mrq;
> -	struct mmc_data *data = mrq->data;
>
>   	cancel_delayed_work_sync(&host->timeout_work);
>
> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   	case MMCIF_WAIT_FOR_READ_END:
>   	case MMCIF_WAIT_FOR_WRITE_END:
>   		if (host->sd_error)
> -			data->error = sh_mmcif_error_manage(host);
> +			mrq->data->error = sh_mmcif_error_manage(host);
>   		break;
>   	default:
>   		BUG();
>   	}
>
>   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> +		struct mmc_data *data = mrq->data;
>   		if (!mrq->cmd->error && data && !data->error)
>   			data->bytes_xfered =
>   				data->blocks * data->blksz;
>

I tried this patch. It seems better.
But I think this still have potential race condition.
I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to 
host->wait_for for new request at the same time.
How about add this code at the top of sh_mmcif_irqt or before returning 
IRQ_WAKE_THREAD in sh_mmcif_intr ?

	if (host->state == STATE_IDLE)
		return IRQ_HANDLED;

I will rebase my test environment to v3.6-rc3 or later. Then I will
send you my .config.

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi

(2012/08/31 12:05), Tetsuyuki Kobayashi wrote:

> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>> interrupts without any active request. To prevent the Oops, that results
>> in such cases, don't dereference the mmc request pointer until we make
>> sure, that we are indeed processing such a request.
>>
>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> ---
>>
>> Hello Kobayashi-san
>>
>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>>
>> ...
>>
>>> After applying this patch on kzm9g board, I got this error regarding
>>> eMMC.
>>> I think this is another problem.
>>>
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address
>>> 00000008
>>> pgd = c0004000
>>> [00000008] *pgd\0000000
>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>>> Modules linked in:
>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>>> PC is at sh_mmcif_irqt+0x20/0xb30
>>> LR is at irq_thread+0x94/0x16c
>>
>> [snip]
>>
>>> My quick fix is below.
>>>
>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>> index 5d81427..e587fbc 100644
>>> --- a/drivers/mmc/host/sh_mmcif.c
>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>> *dev_id)
>>>   {
>>>          struct sh_mmcif_host *host = dev_id;
>>>          struct mmc_request *mrq = host->mrq;
>>> -       struct mmc_data *data = mrq->data;
>>> +       /*struct mmc_data *data = mrq->data; -- this cause null
>>> pointer access*/
>>> +       struct mmc_data *data;
>>> +
>>> +       /* quick fix by koba */
>>> +       if (mrq = NULL) {
>>> +               printk("sh_mmcif_irqt: mrq = NULL:
>>> host->wait_for=%d\n", host->wait_for);
>>> +       } else {
>>> +               data = mrq->data;
>>> +       }
>>>
>>>          cancel_delayed_work_sync(&host->timeout_work);
>>>
>>>
>>> With this patch, there is no null pointer accesses and got this log.
>>>
>>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>>>    ...
>>>
>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>>> There is code such like:
>>>
>>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>>         host->mrq = NULL;
>>>
>>> So, at the top of sh_mmcif_irqt, if host->wait_for =
>>> MMCIF_WAIT_FOR_REQUEST,
>>> host->mrq = NULL.
>>> It is too earlier to access mrq->data before checking host->mrq. it may
>>> cause null pointer access.
>>>
>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>>
>> Thanks for your report and a fix. Could you please double-check, whether
>> the below patch also fixes your problem? Since such spurious interrupts
>> are possible I would commit a check like this one, but in the longer run
>> we want to identify and eliminate them, if possible. But since so far
>> these interrupts only happen on 1 board model and also not on all units
>> and not upon each boot, this could be a bit tricky.
>>
>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>>
>> Thanks
>> Guennadi
>>
>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..82bf921 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>> *dev_id)
>>   {
>>       struct sh_mmcif_host *host = dev_id;
>>       struct mmc_request *mrq = host->mrq;
>> -    struct mmc_data *data = mrq->data;
>>
>>       cancel_delayed_work_sync(&host->timeout_work);
>>
>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>> *dev_id)
>>       case MMCIF_WAIT_FOR_READ_END:
>>       case MMCIF_WAIT_FOR_WRITE_END:
>>           if (host->sd_error)
>> -            data->error = sh_mmcif_error_manage(host);
>> +            mrq->data->error = sh_mmcif_error_manage(host);
>>           break;
>>       default:
>>           BUG();
>>       }
>>
>>       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>> +        struct mmc_data *data = mrq->data;
>>           if (!mrq->cmd->error && data && !data->error)
>>               data->bytes_xfered >>                   data->blocks * data->blksz;
>>
>
> I tried this patch. It seems better.
> But I think this still have potential race condition.
> I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
> host->wait_for for new request at the same time.
> How about add this code at the top of sh_mmcif_irqt or before returning
> IRQ_WAKE_THREAD in sh_mmcif_intr ?
>
>      if (host->state = STATE_IDLE)
>          return IRQ_HANDLED;
>
> I will rebase my test environment to v3.6-rc3 or later. Then I will
> send you my .config.
>
How is this?
I hope this fixed in v3.6.

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi

(2012/08/31 12:05), Tetsuyuki Kobayashi wrote:

> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>> interrupts without any active request. To prevent the Oops, that results
>> in such cases, don't dereference the mmc request pointer until we make
>> sure, that we are indeed processing such a request.
>>
>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> ---
>>
>> Hello Kobayashi-san
>>
>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>>
>> ...
>>
>>> After applying this patch on kzm9g board, I got this error regarding
>>> eMMC.
>>> I think this is another problem.
>>>
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address
>>> 00000008
>>> pgd = c0004000
>>> [00000008] *pgd=00000000
>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>>> Modules linked in:
>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>>> PC is at sh_mmcif_irqt+0x20/0xb30
>>> LR is at irq_thread+0x94/0x16c
>>
>> [snip]
>>
>>> My quick fix is below.
>>>
>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>> index 5d81427..e587fbc 100644
>>> --- a/drivers/mmc/host/sh_mmcif.c
>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>> *dev_id)
>>>   {
>>>          struct sh_mmcif_host *host = dev_id;
>>>          struct mmc_request *mrq = host->mrq;
>>> -       struct mmc_data *data = mrq->data;
>>> +       /*struct mmc_data *data = mrq->data; -- this cause null
>>> pointer access*/
>>> +       struct mmc_data *data;
>>> +
>>> +       /* quick fix by koba */
>>> +       if (mrq == NULL) {
>>> +               printk("sh_mmcif_irqt: mrq == NULL:
>>> host->wait_for=%d\n", host->wait_for);
>>> +       } else {
>>> +               data = mrq->data;
>>> +       }
>>>
>>>          cancel_delayed_work_sync(&host->timeout_work);
>>>
>>>
>>> With this patch, there is no null pointer accesses and got this log.
>>>
>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>>    ...
>>>
>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>>> There is code such like:
>>>
>>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>>         host->mrq = NULL;
>>>
>>> So, at the top of sh_mmcif_irqt, if host->wait_for ==
>>> MMCIF_WAIT_FOR_REQUEST,
>>> host->mrq = NULL.
>>> It is too earlier to access mrq->data before checking host->mrq. it may
>>> cause null pointer access.
>>>
>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>>
>> Thanks for your report and a fix. Could you please double-check, whether
>> the below patch also fixes your problem? Since such spurious interrupts
>> are possible I would commit a check like this one, but in the longer run
>> we want to identify and eliminate them, if possible. But since so far
>> these interrupts only happen on 1 board model and also not on all units
>> and not upon each boot, this could be a bit tricky.
>>
>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>>
>> Thanks
>> Guennadi
>>
>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..82bf921 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>> *dev_id)
>>   {
>>       struct sh_mmcif_host *host = dev_id;
>>       struct mmc_request *mrq = host->mrq;
>> -    struct mmc_data *data = mrq->data;
>>
>>       cancel_delayed_work_sync(&host->timeout_work);
>>
>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>> *dev_id)
>>       case MMCIF_WAIT_FOR_READ_END:
>>       case MMCIF_WAIT_FOR_WRITE_END:
>>           if (host->sd_error)
>> -            data->error = sh_mmcif_error_manage(host);
>> +            mrq->data->error = sh_mmcif_error_manage(host);
>>           break;
>>       default:
>>           BUG();
>>       }
>>
>>       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>> +        struct mmc_data *data = mrq->data;
>>           if (!mrq->cmd->error && data && !data->error)
>>               data->bytes_xfered =
>>                   data->blocks * data->blksz;
>>
>
> I tried this patch. It seems better.
> But I think this still have potential race condition.
> I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
> host->wait_for for new request at the same time.
> How about add this code at the top of sh_mmcif_irqt or before returning
> IRQ_WAKE_THREAD in sh_mmcif_intr ?
>
>      if (host->state == STATE_IDLE)
>          return IRQ_HANDLED;
>
> I will rebase my test environment to v3.6-rc3 or later. Then I will
> send you my .config.
>
How is this?
I hope this fixed in v3.6.

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Guennadi Liakhovetski]

Hello Kobayashi-san

On Tue, 18 Sep 2012, Tetsuyuki Kobayashi wrote:

> Hello Guennadi
> 
> (2012/08/31 12:05), Tetsuyuki Kobayashi wrote:
> 
> > (2012/08/22 15:49), Guennadi Liakhovetski wrote:
> > > On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> > > interrupts without any active request. To prevent the Oops, that results
> > > in such cases, don't dereference the mmc request pointer until we make
> > > sure, that we are indeed processing such a request.
> > > 
> > > Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > > ---
> > > 
> > > Hello Kobayashi-san
> > > 
> > > On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
> > > 
> > > ...
> > > 
> > > > After applying this patch on kzm9g board, I got this error regarding
> > > > eMMC.
> > > > I think this is another problem.
> > > > 
> > > > 
> > > > Unable to handle kernel NULL pointer dereference at virtual address
> > > > 00000008
> > > > pgd = c0004000
> > > > [00000008] *pgd\0000000
> > > > Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> > > > Modules linked in:
> > > > CPU: 1    Not tainted  (3.6.0-rc2+ #103)
> > > > PC is at sh_mmcif_irqt+0x20/0xb30
> > > > LR is at irq_thread+0x94/0x16c
> > > 
> > > [snip]
> > > 
> > > > My quick fix is below.
> > > > 
> > > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > > index 5d81427..e587fbc 100644
> > > > --- a/drivers/mmc/host/sh_mmcif.c
> > > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > > @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > > *dev_id)
> > > >   {
> > > >          struct sh_mmcif_host *host = dev_id;
> > > >          struct mmc_request *mrq = host->mrq;
> > > > -       struct mmc_data *data = mrq->data;
> > > > +       /*struct mmc_data *data = mrq->data; -- this cause null
> > > > pointer access*/
> > > > +       struct mmc_data *data;
> > > > +
> > > > +       /* quick fix by koba */
> > > > +       if (mrq = NULL) {
> > > > +               printk("sh_mmcif_irqt: mrq = NULL:
> > > > host->wait_for=%d\n", host->wait_for);
> > > > +       } else {
> > > > +               data = mrq->data;
> > > > +       }
> > > > 
> > > >          cancel_delayed_work_sync(&host->timeout_work);
> > > > 
> > > > 
> > > > With this patch, there is no null pointer accesses and got this log.
> > > > 
> > > > sh_mmcif_irqt: mrq = NULL: host->wait_for=0
> > > > sh_mmcif_irqt: mrq = NULL: host->wait_for=0
> > > >    ...
> > > > 
> > > > host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
> > > > There is code such like:
> > > > 
> > > >         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
> > > >         host->mrq = NULL;
> > > > 
> > > > So, at the top of sh_mmcif_irqt, if host->wait_for =
> > > > MMCIF_WAIT_FOR_REQUEST,
> > > > host->mrq = NULL.
> > > > It is too earlier to access mrq->data before checking host->mrq. it may
> > > > cause null pointer access.
> > > > 
> > > > Goda-san, could you check this and refine the code of sh_mmcif_irqt?
> > > 
> > > Thanks for your report and a fix. Could you please double-check, whether
> > > the below patch also fixes your problem? Since such spurious interrupts
> > > are possible I would commit a check like this one, but in the longer run
> > > we want to identify and eliminate them, if possible. But since so far
> > > these interrupts only happen on 1 board model and also not on all units
> > > and not upon each boot, this could be a bit tricky.
> > > 
> > > One more question - is this only needed for 3.7 or also for 3.6 / stable?
> > > 
> > > Thanks
> > > Guennadi
> > > 
> > >   drivers/mmc/host/sh_mmcif.c |    4 ++--
> > >   1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > index 5d81427..82bf921 100644
> > > --- a/drivers/mmc/host/sh_mmcif.c
> > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > *dev_id)
> > >   {
> > >       struct sh_mmcif_host *host = dev_id;
> > >       struct mmc_request *mrq = host->mrq;
> > > -    struct mmc_data *data = mrq->data;
> > > 
> > >       cancel_delayed_work_sync(&host->timeout_work);
> > > 
> > > @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > *dev_id)
> > >       case MMCIF_WAIT_FOR_READ_END:
> > >       case MMCIF_WAIT_FOR_WRITE_END:
> > >           if (host->sd_error)
> > > -            data->error = sh_mmcif_error_manage(host);
> > > +            mrq->data->error = sh_mmcif_error_manage(host);
> > >           break;
> > >       default:
> > >           BUG();
> > >       }
> > > 
> > >       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> > > +        struct mmc_data *data = mrq->data;
> > >           if (!mrq->cmd->error && data && !data->error)
> > >               data->bytes_xfered > > >                   data->blocks * data->blksz;
> > > 
> > 
> > I tried this patch. It seems better.
> > But I think this still have potential race condition.
> > I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
> > host->wait_for for new request at the same time.
> > How about add this code at the top of sh_mmcif_irqt or before returning
> > IRQ_WAKE_THREAD in sh_mmcif_intr ?
> > 
> >      if (host->state = STATE_IDLE)
> >          return IRQ_HANDLED;
> > 
> > I will rebase my test environment to v3.6-rc3 or later. Then I will
> > send you my .config.
> > 
> How is this?
> I hope this fixed in v3.6.

Sorry, I still haven't come round to looking at this. I think, one thing 
could halp, if you could try to find out what exactly those spurious 
interrupts look like, i.e., what's their interrupt status? You could try 
to print like

diff -u a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1229,6 +1229,10 @@
 		host->sd_error = true;
 		dev_dbg(&host->pd->dev, "int err state = %08x\n", state);
 	}
+	if (host->state = STATE_IDLE) {
+		dev_info(&host->pd->dev, "Spurious IRQ status 0x%x", state);
+		return IRQ_HANDLED;
+	}
 	if (state & ~(INT_CMD12RBE | INT_CMD12CRE)) {
 		if (!host->dma_active)
 			return IRQ_WAKE_THREAD;

Please, let me know, if it's not very easy for you ATM to perform the 
test, I'll try to do it myself then.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Guennadi Liakhovetski]

Hello Kobayashi-san

On Tue, 18 Sep 2012, Tetsuyuki Kobayashi wrote:

> Hello Guennadi
> 
> (2012/08/31 12:05), Tetsuyuki Kobayashi wrote:
> 
> > (2012/08/22 15:49), Guennadi Liakhovetski wrote:
> > > On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> > > interrupts without any active request. To prevent the Oops, that results
> > > in such cases, don't dereference the mmc request pointer until we make
> > > sure, that we are indeed processing such a request.
> > > 
> > > Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > > ---
> > > 
> > > Hello Kobayashi-san
> > > 
> > > On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
> > > 
> > > ...
> > > 
> > > > After applying this patch on kzm9g board, I got this error regarding
> > > > eMMC.
> > > > I think this is another problem.
> > > > 
> > > > 
> > > > Unable to handle kernel NULL pointer dereference at virtual address
> > > > 00000008
> > > > pgd = c0004000
> > > > [00000008] *pgd=00000000
> > > > Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> > > > Modules linked in:
> > > > CPU: 1    Not tainted  (3.6.0-rc2+ #103)
> > > > PC is at sh_mmcif_irqt+0x20/0xb30
> > > > LR is at irq_thread+0x94/0x16c
> > > 
> > > [snip]
> > > 
> > > > My quick fix is below.
> > > > 
> > > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > > index 5d81427..e587fbc 100644
> > > > --- a/drivers/mmc/host/sh_mmcif.c
> > > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > > @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > > *dev_id)
> > > >   {
> > > >          struct sh_mmcif_host *host = dev_id;
> > > >          struct mmc_request *mrq = host->mrq;
> > > > -       struct mmc_data *data = mrq->data;
> > > > +       /*struct mmc_data *data = mrq->data; -- this cause null
> > > > pointer access*/
> > > > +       struct mmc_data *data;
> > > > +
> > > > +       /* quick fix by koba */
> > > > +       if (mrq == NULL) {
> > > > +               printk("sh_mmcif_irqt: mrq == NULL:
> > > > host->wait_for=%d\n", host->wait_for);
> > > > +       } else {
> > > > +               data = mrq->data;
> > > > +       }
> > > > 
> > > >          cancel_delayed_work_sync(&host->timeout_work);
> > > > 
> > > > 
> > > > With this patch, there is no null pointer accesses and got this log.
> > > > 
> > > > sh_mmcif_irqt: mrq == NULL: host->wait_for=0
> > > > sh_mmcif_irqt: mrq == NULL: host->wait_for=0
> > > >    ...
> > > > 
> > > > host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
> > > > There is code such like:
> > > > 
> > > >         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
> > > >         host->mrq = NULL;
> > > > 
> > > > So, at the top of sh_mmcif_irqt, if host->wait_for ==
> > > > MMCIF_WAIT_FOR_REQUEST,
> > > > host->mrq = NULL.
> > > > It is too earlier to access mrq->data before checking host->mrq. it may
> > > > cause null pointer access.
> > > > 
> > > > Goda-san, could you check this and refine the code of sh_mmcif_irqt?
> > > 
> > > Thanks for your report and a fix. Could you please double-check, whether
> > > the below patch also fixes your problem? Since such spurious interrupts
> > > are possible I would commit a check like this one, but in the longer run
> > > we want to identify and eliminate them, if possible. But since so far
> > > these interrupts only happen on 1 board model and also not on all units
> > > and not upon each boot, this could be a bit tricky.
> > > 
> > > One more question - is this only needed for 3.7 or also for 3.6 / stable?
> > > 
> > > Thanks
> > > Guennadi
> > > 
> > >   drivers/mmc/host/sh_mmcif.c |    4 ++--
> > >   1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > index 5d81427..82bf921 100644
> > > --- a/drivers/mmc/host/sh_mmcif.c
> > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > *dev_id)
> > >   {
> > >       struct sh_mmcif_host *host = dev_id;
> > >       struct mmc_request *mrq = host->mrq;
> > > -    struct mmc_data *data = mrq->data;
> > > 
> > >       cancel_delayed_work_sync(&host->timeout_work);
> > > 
> > > @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > *dev_id)
> > >       case MMCIF_WAIT_FOR_READ_END:
> > >       case MMCIF_WAIT_FOR_WRITE_END:
> > >           if (host->sd_error)
> > > -            data->error = sh_mmcif_error_manage(host);
> > > +            mrq->data->error = sh_mmcif_error_manage(host);
> > >           break;
> > >       default:
> > >           BUG();
> > >       }
> > > 
> > >       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> > > +        struct mmc_data *data = mrq->data;
> > >           if (!mrq->cmd->error && data && !data->error)
> > >               data->bytes_xfered =
> > >                   data->blocks * data->blksz;
> > > 
> > 
> > I tried this patch. It seems better.
> > But I think this still have potential race condition.
> > I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
> > host->wait_for for new request at the same time.
> > How about add this code at the top of sh_mmcif_irqt or before returning
> > IRQ_WAKE_THREAD in sh_mmcif_intr ?
> > 
> >      if (host->state == STATE_IDLE)
> >          return IRQ_HANDLED;
> > 
> > I will rebase my test environment to v3.6-rc3 or later. Then I will
> > send you my .config.
> > 
> How is this?
> I hope this fixed in v3.6.

Sorry, I still haven't come round to looking at this. I think, one thing 
could halp, if you could try to find out what exactly those spurious 
interrupts look like, i.e., what's their interrupt status? You could try 
to print like

diff -u a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1229,6 +1229,10 @@
 		host->sd_error = true;
 		dev_dbg(&host->pd->dev, "int err state = %08x\n", state);
 	}
+	if (host->state == STATE_IDLE) {
+		dev_info(&host->pd->dev, "Spurious IRQ status 0x%x", state);
+		return IRQ_HANDLED;
+	}
 	if (state & ~(INT_CMD12RBE | INT_CMD12CRE)) {
 		if (!host->dma_active)
 			return IRQ_WAKE_THREAD;

Please, let me know, if it's not very easy for you ATM to perform the 
test, I'll try to do it myself then.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi

(09/18/2012 03:42 PM), Guennadi Liakhovetski wrote:
> Hello Kobayashi-san
> 
> On Tue, 18 Sep 2012, Tetsuyuki Kobayashi wrote:
> 
>> Hello Guennadi
>>
>> (2012/08/31 12:05), Tetsuyuki Kobayashi wrote:
>>
>>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>>>> interrupts without any active request. To prevent the Oops, that results
>>>> in such cases, don't dereference the mmc request pointer until we make
>>>> sure, that we are indeed processing such a request.
>>>>
>>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>>>> ---
>>>>
>>>> Hello Kobayashi-san
>>>>
>>>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>>>>
>>>> ...
>>>>
>>>>> After applying this patch on kzm9g board, I got this error regarding
>>>>> eMMC.
>>>>> I think this is another problem.
>>>>>
>>>>>
>>>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>>> 00000008
>>>>> pgd = c0004000
>>>>> [00000008] *pgd\0000000
>>>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>>>>> Modules linked in:
>>>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>>>>> PC is at sh_mmcif_irqt+0x20/0xb30
>>>>> LR is at irq_thread+0x94/0x16c
>>>>
>>>> [snip]
>>>>
>>>>> My quick fix is below.
>>>>>
>>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>>> index 5d81427..e587fbc 100644
>>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>>> *dev_id)
>>>>>   {
>>>>>          struct sh_mmcif_host *host = dev_id;
>>>>>          struct mmc_request *mrq = host->mrq;
>>>>> -       struct mmc_data *data = mrq->data;
>>>>> +       /*struct mmc_data *data = mrq->data; -- this cause null
>>>>> pointer access*/
>>>>> +       struct mmc_data *data;
>>>>> +
>>>>> +       /* quick fix by koba */
>>>>> +       if (mrq = NULL) {
>>>>> +               printk("sh_mmcif_irqt: mrq = NULL:
>>>>> host->wait_for=%d\n", host->wait_for);
>>>>> +       } else {
>>>>> +               data = mrq->data;
>>>>> +       }
>>>>>
>>>>>          cancel_delayed_work_sync(&host->timeout_work);
>>>>>
>>>>>
>>>>> With this patch, there is no null pointer accesses and got this log.
>>>>>
>>>>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>>>>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>>>>>    ...
>>>>>
>>>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>>>>> There is code such like:
>>>>>
>>>>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>>>>         host->mrq = NULL;
>>>>>
>>>>> So, at the top of sh_mmcif_irqt, if host->wait_for =
>>>>> MMCIF_WAIT_FOR_REQUEST,
>>>>> host->mrq = NULL.
>>>>> It is too earlier to access mrq->data before checking host->mrq. it may
>>>>> cause null pointer access.
>>>>>
>>>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>>>>
>>>> Thanks for your report and a fix. Could you please double-check, whether
>>>> the below patch also fixes your problem? Since such spurious interrupts
>>>> are possible I would commit a check like this one, but in the longer run
>>>> we want to identify and eliminate them, if possible. But since so far
>>>> these interrupts only happen on 1 board model and also not on all units
>>>> and not upon each boot, this could be a bit tricky.
>>>>
>>>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>>>>
>>>> Thanks
>>>> Guennadi
>>>>
>>>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>>>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>> index 5d81427..82bf921 100644
>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>> *dev_id)
>>>>   {
>>>>       struct sh_mmcif_host *host = dev_id;
>>>>       struct mmc_request *mrq = host->mrq;
>>>> -    struct mmc_data *data = mrq->data;
>>>>
>>>>       cancel_delayed_work_sync(&host->timeout_work);
>>>>
>>>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>> *dev_id)
>>>>       case MMCIF_WAIT_FOR_READ_END:
>>>>       case MMCIF_WAIT_FOR_WRITE_END:
>>>>           if (host->sd_error)
>>>> -            data->error = sh_mmcif_error_manage(host);
>>>> +            mrq->data->error = sh_mmcif_error_manage(host);
>>>>           break;
>>>>       default:
>>>>           BUG();
>>>>       }
>>>>
>>>>       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>>>> +        struct mmc_data *data = mrq->data;
>>>>           if (!mrq->cmd->error && data && !data->error)
>>>>               data->bytes_xfered >>>>                   data->blocks * data->blksz;
>>>>
>>>
>>> I tried this patch. It seems better.
>>> But I think this still have potential race condition.
>>> I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
>>> host->wait_for for new request at the same time.
>>> How about add this code at the top of sh_mmcif_irqt or before returning
>>> IRQ_WAKE_THREAD in sh_mmcif_intr ?
>>>
>>>      if (host->state = STATE_IDLE)
>>>          return IRQ_HANDLED;
>>>
>>> I will rebase my test environment to v3.6-rc3 or later. Then I will
>>> send you my .config.
>>>
>> How is this?
>> I hope this fixed in v3.6.
> 
> Sorry, I still haven't come round to looking at this. I think, one thing 
> could halp, if you could try to find out what exactly those spurious 
> interrupts look like, i.e., what's their interrupt status? You could try 
> to print like
> 
> diff -u a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1229,6 +1229,10 @@
>  		host->sd_error = true;
>  		dev_dbg(&host->pd->dev, "int err state = %08x\n", state);
>  	}
> +	if (host->state = STATE_IDLE) {
> +		dev_info(&host->pd->dev, "Spurious IRQ status 0x%x", state);
> +		return IRQ_HANDLED;
> +	}
>  	if (state & ~(INT_CMD12RBE | INT_CMD12CRE)) {
>  		if (!host->dma_active)
>  			return IRQ_WAKE_THREAD;
> 
> Please, let me know, if it's not very easy for you ATM to perform the 
> test, I'll try to do it myself then.

OK. It is easy for me.
I got this log after mounting /dev/mmcblk2p1 (on eMMC) and executing
tar command to make file accesses.
This is based on v3.6-rc6.

[  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
[  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
[  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  221.585937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.039062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.382812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.109375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.406250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.734375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.750000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  224.398437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  230.289062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi

(09/18/2012 03:42 PM), Guennadi Liakhovetski wrote:
> Hello Kobayashi-san
> 
> On Tue, 18 Sep 2012, Tetsuyuki Kobayashi wrote:
> 
>> Hello Guennadi
>>
>> (2012/08/31 12:05), Tetsuyuki Kobayashi wrote:
>>
>>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>>>> interrupts without any active request. To prevent the Oops, that results
>>>> in such cases, don't dereference the mmc request pointer until we make
>>>> sure, that we are indeed processing such a request.
>>>>
>>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>>>> ---
>>>>
>>>> Hello Kobayashi-san
>>>>
>>>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>>>>
>>>> ...
>>>>
>>>>> After applying this patch on kzm9g board, I got this error regarding
>>>>> eMMC.
>>>>> I think this is another problem.
>>>>>
>>>>>
>>>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>>> 00000008
>>>>> pgd = c0004000
>>>>> [00000008] *pgd=00000000
>>>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>>>>> Modules linked in:
>>>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>>>>> PC is at sh_mmcif_irqt+0x20/0xb30
>>>>> LR is at irq_thread+0x94/0x16c
>>>>
>>>> [snip]
>>>>
>>>>> My quick fix is below.
>>>>>
>>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>>> index 5d81427..e587fbc 100644
>>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>>> *dev_id)
>>>>>   {
>>>>>          struct sh_mmcif_host *host = dev_id;
>>>>>          struct mmc_request *mrq = host->mrq;
>>>>> -       struct mmc_data *data = mrq->data;
>>>>> +       /*struct mmc_data *data = mrq->data; -- this cause null
>>>>> pointer access*/
>>>>> +       struct mmc_data *data;
>>>>> +
>>>>> +       /* quick fix by koba */
>>>>> +       if (mrq == NULL) {
>>>>> +               printk("sh_mmcif_irqt: mrq == NULL:
>>>>> host->wait_for=%d\n", host->wait_for);
>>>>> +       } else {
>>>>> +               data = mrq->data;
>>>>> +       }
>>>>>
>>>>>          cancel_delayed_work_sync(&host->timeout_work);
>>>>>
>>>>>
>>>>> With this patch, there is no null pointer accesses and got this log.
>>>>>
>>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>>>>    ...
>>>>>
>>>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>>>>> There is code such like:
>>>>>
>>>>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>>>>         host->mrq = NULL;
>>>>>
>>>>> So, at the top of sh_mmcif_irqt, if host->wait_for ==
>>>>> MMCIF_WAIT_FOR_REQUEST,
>>>>> host->mrq = NULL.
>>>>> It is too earlier to access mrq->data before checking host->mrq. it may
>>>>> cause null pointer access.
>>>>>
>>>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>>>>
>>>> Thanks for your report and a fix. Could you please double-check, whether
>>>> the below patch also fixes your problem? Since such spurious interrupts
>>>> are possible I would commit a check like this one, but in the longer run
>>>> we want to identify and eliminate them, if possible. But since so far
>>>> these interrupts only happen on 1 board model and also not on all units
>>>> and not upon each boot, this could be a bit tricky.
>>>>
>>>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>>>>
>>>> Thanks
>>>> Guennadi
>>>>
>>>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>>>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>> index 5d81427..82bf921 100644
>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>> *dev_id)
>>>>   {
>>>>       struct sh_mmcif_host *host = dev_id;
>>>>       struct mmc_request *mrq = host->mrq;
>>>> -    struct mmc_data *data = mrq->data;
>>>>
>>>>       cancel_delayed_work_sync(&host->timeout_work);
>>>>
>>>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>> *dev_id)
>>>>       case MMCIF_WAIT_FOR_READ_END:
>>>>       case MMCIF_WAIT_FOR_WRITE_END:
>>>>           if (host->sd_error)
>>>> -            data->error = sh_mmcif_error_manage(host);
>>>> +            mrq->data->error = sh_mmcif_error_manage(host);
>>>>           break;
>>>>       default:
>>>>           BUG();
>>>>       }
>>>>
>>>>       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>>>> +        struct mmc_data *data = mrq->data;
>>>>           if (!mrq->cmd->error && data && !data->error)
>>>>               data->bytes_xfered =
>>>>                   data->blocks * data->blksz;
>>>>
>>>
>>> I tried this patch. It seems better.
>>> But I think this still have potential race condition.
>>> I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
>>> host->wait_for for new request at the same time.
>>> How about add this code at the top of sh_mmcif_irqt or before returning
>>> IRQ_WAKE_THREAD in sh_mmcif_intr ?
>>>
>>>      if (host->state == STATE_IDLE)
>>>          return IRQ_HANDLED;
>>>
>>> I will rebase my test environment to v3.6-rc3 or later. Then I will
>>> send you my .config.
>>>
>> How is this?
>> I hope this fixed in v3.6.
> 
> Sorry, I still haven't come round to looking at this. I think, one thing 
> could halp, if you could try to find out what exactly those spurious 
> interrupts look like, i.e., what's their interrupt status? You could try 
> to print like
> 
> diff -u a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1229,6 +1229,10 @@
>  		host->sd_error = true;
>  		dev_dbg(&host->pd->dev, "int err state = %08x\n", state);
>  	}
> +	if (host->state == STATE_IDLE) {
> +		dev_info(&host->pd->dev, "Spurious IRQ status 0x%x", state);
> +		return IRQ_HANDLED;
> +	}
>  	if (state & ~(INT_CMD12RBE | INT_CMD12CRE)) {
>  		if (!host->dma_active)
>  			return IRQ_WAKE_THREAD;
> 
> Please, let me know, if it's not very easy for you ATM to perform the 
> test, I'll try to do it myself then.

OK. It is easy for me.
I got this log after mounting /dev/mmcblk2p1 (on eMMC) and executing
tar command to make file accesses.
This is based on v3.6-rc6.

[  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
[  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
[  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  221.585937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.039062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.382812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.109375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.406250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.734375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.750000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  224.398437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  230.289062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi

(09/18/2012 05:02 PM), Tetsuyuki Kobayashi wrote:

>>>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>>>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>>>>> interrupts without any active request. To prevent the Oops, that results
>>>>> in such cases, don't dereference the mmc request pointer until we make
>>>>> sure, that we are indeed processing such a request.
>>>>>
>>>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>>>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>>>>> ---
>>>>>
>>>>> Hello Kobayashi-san
>>>>>
>>>>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>> After applying this patch on kzm9g board, I got this error regarding
>>>>>> eMMC.
>>>>>> I think this is another problem.
>>>>>>
>>>>>>
>>>>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>>>> 00000008
>>>>>> pgd = c0004000
>>>>>> [00000008] *pgd\0000000
>>>>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>>>>>> Modules linked in:
>>>>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>>>>>> PC is at sh_mmcif_irqt+0x20/0xb30
>>>>>> LR is at irq_thread+0x94/0x16c
>>>>>
>>>>> [snip]
>>>>>
>>>>>> My quick fix is below.
>>>>>>
>>>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>>>> index 5d81427..e587fbc 100644
>>>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>>>> *dev_id)
>>>>>>   {
>>>>>>          struct sh_mmcif_host *host = dev_id;
>>>>>>          struct mmc_request *mrq = host->mrq;
>>>>>> -       struct mmc_data *data = mrq->data;
>>>>>> +       /*struct mmc_data *data = mrq->data; -- this cause null
>>>>>> pointer access*/
>>>>>> +       struct mmc_data *data;
>>>>>> +
>>>>>> +       /* quick fix by koba */
>>>>>> +       if (mrq = NULL) {
>>>>>> +               printk("sh_mmcif_irqt: mrq = NULL:
>>>>>> host->wait_for=%d\n", host->wait_for);
>>>>>> +       } else {
>>>>>> +               data = mrq->data;
>>>>>> +       }
>>>>>>
>>>>>>          cancel_delayed_work_sync(&host->timeout_work);
>>>>>>
>>>>>>
>>>>>> With this patch, there is no null pointer accesses and got this log.
>>>>>>
>>>>>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>>>>>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>>>>>>    ...
>>>>>>
>>>>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>>>>>> There is code such like:
>>>>>>
>>>>>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>>>>>         host->mrq = NULL;
>>>>>>
>>>>>> So, at the top of sh_mmcif_irqt, if host->wait_for =
>>>>>> MMCIF_WAIT_FOR_REQUEST,
>>>>>> host->mrq = NULL.
>>>>>> It is too earlier to access mrq->data before checking host->mrq. it may
>>>>>> cause null pointer access.
>>>>>>
>>>>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>>>>>
>>>>> Thanks for your report and a fix. Could you please double-check, whether
>>>>> the below patch also fixes your problem? Since such spurious interrupts
>>>>> are possible I would commit a check like this one, but in the longer run
>>>>> we want to identify and eliminate them, if possible. But since so far
>>>>> these interrupts only happen on 1 board model and also not on all units
>>>>> and not upon each boot, this could be a bit tricky.
>>>>>
>>>>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>>>>>
>>>>> Thanks
>>>>> Guennadi
>>>>>
>>>>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>>>>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>>> index 5d81427..82bf921 100644
>>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>>> *dev_id)
>>>>>   {
>>>>>       struct sh_mmcif_host *host = dev_id;
>>>>>       struct mmc_request *mrq = host->mrq;
>>>>> -    struct mmc_data *data = mrq->data;
>>>>>
>>>>>       cancel_delayed_work_sync(&host->timeout_work);
>>>>>
>>>>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>>> *dev_id)
>>>>>       case MMCIF_WAIT_FOR_READ_END:
>>>>>       case MMCIF_WAIT_FOR_WRITE_END:
>>>>>           if (host->sd_error)
>>>>> -            data->error = sh_mmcif_error_manage(host);
>>>>> +            mrq->data->error = sh_mmcif_error_manage(host);
>>>>>           break;
>>>>>       default:
>>>>>           BUG();
>>>>>       }
>>>>>
>>>>>       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>>>>> +        struct mmc_data *data = mrq->data;
>>>>>           if (!mrq->cmd->error && data && !data->error)
>>>>>               data->bytes_xfered >>>>>                   data->blocks * data->blksz;
>>>>>
>>>>
>>>> I tried this patch. It seems better.
>>>> But I think this still have potential race condition.
>>>> I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
>>>> host->wait_for for new request at the same time.
>>>> How about add this code at the top of sh_mmcif_irqt or before returning
>>>> IRQ_WAKE_THREAD in sh_mmcif_intr ?
>>>>
>>>>      if (host->state = STATE_IDLE)
>>>>          return IRQ_HANDLED;
>>>>
>>>> I will rebase my test environment to v3.6-rc3 or later. Then I will
>>>> send you my .config.
>>>>
>>> How is this?
>>> I hope this fixed in v3.6.
>>
>> Sorry, I still haven't come round to looking at this. I think, one thing 
>> could halp, if you could try to find out what exactly those spurious 
>> interrupts look like, i.e., what's their interrupt status? You could try 
>> to print like
>>
>> diff -u a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1229,6 +1229,10 @@
>>  		host->sd_error = true;
>>  		dev_dbg(&host->pd->dev, "int err state = %08x\n", state);
>>  	}
>> +	if (host->state = STATE_IDLE) {
>> +		dev_info(&host->pd->dev, "Spurious IRQ status 0x%x", state);
>> +		return IRQ_HANDLED;
>> +	}
>>  	if (state & ~(INT_CMD12RBE | INT_CMD12CRE)) {
>>  		if (!host->dma_active)
>>  			return IRQ_WAKE_THREAD;
>>
>> Please, let me know, if it's not very easy for you ATM to perform the 
>> test, I'll try to do it myself then.
> 
> OK. It is easy for me.
> I got this log after mounting /dev/mmcblk2p1 (on eMMC) and executing
> tar command to make file accesses.
> This is based on v3.6-rc6.
> 
> [  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
> [  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
> [  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  221.585937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  222.039062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  222.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  222.382812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  223.109375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  223.406250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  223.734375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  223.750000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  224.398437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  230.289062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> 
It might too earlier to report. I got this log.

[  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
[  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
[  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  221.585937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.039062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.382812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.109375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.406250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.734375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.750000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  224.398437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  230.289062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  998.554687] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1063.695312] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1663.203125] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1675.007812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1683.898437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1684.187500] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1684.343750] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1686.390625] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1687.843750] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1687.921875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1687.976562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1692.101562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1692.281250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1692.476562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1692.960937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1693.062500] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1696.195312] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1702.140625] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3800000
[ 1702.148437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1719.453125] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1719.476562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3800000
[ 1721.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.484375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.507812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.781250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.804687] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.828125] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.851562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1722.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.437500] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.453125] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.484375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.507812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.531250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1934.296875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[ 1935.125000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[ 1968.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000


After that, I tried the same thing without DMA by comment out like this.
In this case spurious IRQ never occurred. 

diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board
index 765f60a..d5e6609 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -389,8 +389,8 @@ static struct resource sh_mmcif_resources[] = {
 static struct sh_mmcif_plat_data sh_mmcif_platdata = {
        .ocr            = MMC_VDD_165_195,
        .caps           = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
-       .slave_id_tx    = SHDMA_SLAVE_MMCIF_TX,
-       .slave_id_rx    = SHDMA_SLAVE_MMCIF_RX,
+       /*.slave_id_tx  = SHDMA_SLAVE_MMCIF_TX,*/
+       /*.slave_id_rx  = SHDMA_SLAVE_MMCIF_RX,*/
 };

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi

(09/18/2012 05:02 PM), Tetsuyuki Kobayashi wrote:

>>>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>>>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>>>>> interrupts without any active request. To prevent the Oops, that results
>>>>> in such cases, don't dereference the mmc request pointer until we make
>>>>> sure, that we are indeed processing such a request.
>>>>>
>>>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>>>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>>>>> ---
>>>>>
>>>>> Hello Kobayashi-san
>>>>>
>>>>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>> After applying this patch on kzm9g board, I got this error regarding
>>>>>> eMMC.
>>>>>> I think this is another problem.
>>>>>>
>>>>>>
>>>>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>>>> 00000008
>>>>>> pgd = c0004000
>>>>>> [00000008] *pgd=00000000
>>>>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>>>>>> Modules linked in:
>>>>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>>>>>> PC is at sh_mmcif_irqt+0x20/0xb30
>>>>>> LR is at irq_thread+0x94/0x16c
>>>>>
>>>>> [snip]
>>>>>
>>>>>> My quick fix is below.
>>>>>>
>>>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>>>> index 5d81427..e587fbc 100644
>>>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>>>> *dev_id)
>>>>>>   {
>>>>>>          struct sh_mmcif_host *host = dev_id;
>>>>>>          struct mmc_request *mrq = host->mrq;
>>>>>> -       struct mmc_data *data = mrq->data;
>>>>>> +       /*struct mmc_data *data = mrq->data; -- this cause null
>>>>>> pointer access*/
>>>>>> +       struct mmc_data *data;
>>>>>> +
>>>>>> +       /* quick fix by koba */
>>>>>> +       if (mrq == NULL) {
>>>>>> +               printk("sh_mmcif_irqt: mrq == NULL:
>>>>>> host->wait_for=%d\n", host->wait_for);
>>>>>> +       } else {
>>>>>> +               data = mrq->data;
>>>>>> +       }
>>>>>>
>>>>>>          cancel_delayed_work_sync(&host->timeout_work);
>>>>>>
>>>>>>
>>>>>> With this patch, there is no null pointer accesses and got this log.
>>>>>>
>>>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>>>>>    ...
>>>>>>
>>>>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>>>>>> There is code such like:
>>>>>>
>>>>>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>>>>>         host->mrq = NULL;
>>>>>>
>>>>>> So, at the top of sh_mmcif_irqt, if host->wait_for ==
>>>>>> MMCIF_WAIT_FOR_REQUEST,
>>>>>> host->mrq = NULL.
>>>>>> It is too earlier to access mrq->data before checking host->mrq. it may
>>>>>> cause null pointer access.
>>>>>>
>>>>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>>>>>
>>>>> Thanks for your report and a fix. Could you please double-check, whether
>>>>> the below patch also fixes your problem? Since such spurious interrupts
>>>>> are possible I would commit a check like this one, but in the longer run
>>>>> we want to identify and eliminate them, if possible. But since so far
>>>>> these interrupts only happen on 1 board model and also not on all units
>>>>> and not upon each boot, this could be a bit tricky.
>>>>>
>>>>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>>>>>
>>>>> Thanks
>>>>> Guennadi
>>>>>
>>>>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>>>>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>>>>> index 5d81427..82bf921 100644
>>>>> --- a/drivers/mmc/host/sh_mmcif.c
>>>>> +++ b/drivers/mmc/host/sh_mmcif.c
>>>>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>>> *dev_id)
>>>>>   {
>>>>>       struct sh_mmcif_host *host = dev_id;
>>>>>       struct mmc_request *mrq = host->mrq;
>>>>> -    struct mmc_data *data = mrq->data;
>>>>>
>>>>>       cancel_delayed_work_sync(&host->timeout_work);
>>>>>
>>>>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
>>>>> *dev_id)
>>>>>       case MMCIF_WAIT_FOR_READ_END:
>>>>>       case MMCIF_WAIT_FOR_WRITE_END:
>>>>>           if (host->sd_error)
>>>>> -            data->error = sh_mmcif_error_manage(host);
>>>>> +            mrq->data->error = sh_mmcif_error_manage(host);
>>>>>           break;
>>>>>       default:
>>>>>           BUG();
>>>>>       }
>>>>>
>>>>>       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>>>>> +        struct mmc_data *data = mrq->data;
>>>>>           if (!mrq->cmd->error && data && !data->error)
>>>>>               data->bytes_xfered =
>>>>>                   data->blocks * data->blksz;
>>>>>
>>>>
>>>> I tried this patch. It seems better.
>>>> But I think this still have potential race condition.
>>>> I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
>>>> host->wait_for for new request at the same time.
>>>> How about add this code at the top of sh_mmcif_irqt or before returning
>>>> IRQ_WAKE_THREAD in sh_mmcif_intr ?
>>>>
>>>>      if (host->state == STATE_IDLE)
>>>>          return IRQ_HANDLED;
>>>>
>>>> I will rebase my test environment to v3.6-rc3 or later. Then I will
>>>> send you my .config.
>>>>
>>> How is this?
>>> I hope this fixed in v3.6.
>>
>> Sorry, I still haven't come round to looking at this. I think, one thing 
>> could halp, if you could try to find out what exactly those spurious 
>> interrupts look like, i.e., what's their interrupt status? You could try 
>> to print like
>>
>> diff -u a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1229,6 +1229,10 @@
>>  		host->sd_error = true;
>>  		dev_dbg(&host->pd->dev, "int err state = %08x\n", state);
>>  	}
>> +	if (host->state == STATE_IDLE) {
>> +		dev_info(&host->pd->dev, "Spurious IRQ status 0x%x", state);
>> +		return IRQ_HANDLED;
>> +	}
>>  	if (state & ~(INT_CMD12RBE | INT_CMD12CRE)) {
>>  		if (!host->dma_active)
>>  			return IRQ_WAKE_THREAD;
>>
>> Please, let me know, if it's not very easy for you ATM to perform the 
>> test, I'll try to do it myself then.
> 
> OK. It is easy for me.
> I got this log after mounting /dev/mmcblk2p1 (on eMMC) and executing
> tar command to make file accesses.
> This is based on v3.6-rc6.
> 
> [  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
> [  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
> [  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  221.585937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  222.039062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  222.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  222.382812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  223.109375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  223.406250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  223.734375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  223.750000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  224.398437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> [  230.289062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> 
It might too earlier to report. I got this log.

[  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
[  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
[  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  221.585937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.039062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  222.382812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.109375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.406250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.734375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  223.750000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  224.398437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  230.289062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[  998.554687] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1063.695312] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1663.203125] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1675.007812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1683.898437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1684.187500] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1684.343750] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1686.390625] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1687.843750] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1687.921875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1687.976562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1692.101562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1692.281250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1692.476562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1692.960937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1693.062500] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1696.195312] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1702.140625] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3800000
[ 1702.148437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1719.453125] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1719.476562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3800000
[ 1721.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.484375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.507812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.781250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.804687] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.828125] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1721.851562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1722.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.437500] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.453125] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.484375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.507812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1723.531250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
[ 1934.296875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[ 1935.125000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
[ 1968.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000


After that, I tried the same thing without DMA by comment out like this.
In this case spurious IRQ never occurred. 

diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board
index 765f60a..d5e6609 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -389,8 +389,8 @@ static struct resource sh_mmcif_resources[] = {
 static struct sh_mmcif_plat_data sh_mmcif_platdata = {
        .ocr            = MMC_VDD_165_195,
        .caps           = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
-       .slave_id_tx    = SHDMA_SLAVE_MMCIF_TX,
-       .slave_id_rx    = SHDMA_SLAVE_MMCIF_RX,
+       /*.slave_id_tx  = SHDMA_SLAVE_MMCIF_TX,*/
+       /*.slave_id_rx  = SHDMA_SLAVE_MMCIF_RX,*/
 };

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Guennadi Liakhovetski]

On Tue, 18 Sep 2012, Tetsuyuki Kobayashi wrote:

> Hello Guennadi
> 
> (09/18/2012 05:02 PM), Tetsuyuki Kobayashi wrote:
> 
> >>>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
> >>>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> >>>>> interrupts without any active request. To prevent the Oops, that results
> >>>>> in such cases, don't dereference the mmc request pointer until we make
> >>>>> sure, that we are indeed processing such a request.
> >>>>>
> >>>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> >>>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> >>>>> ---
> >>>>>
> >>>>> Hello Kobayashi-san
> >>>>>
> >>>>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
> >>>>>
> >>>>> ...
> >>>>>
> >>>>>> After applying this patch on kzm9g board, I got this error regarding
> >>>>>> eMMC.
> >>>>>> I think this is another problem.
> >>>>>>
> >>>>>>
> >>>>>> Unable to handle kernel NULL pointer dereference at virtual address
> >>>>>> 00000008
> >>>>>> pgd = c0004000
> >>>>>> [00000008] *pgd\0000000
> >>>>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> >>>>>> Modules linked in:
> >>>>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
> >>>>>> PC is at sh_mmcif_irqt+0x20/0xb30
> >>>>>> LR is at irq_thread+0x94/0x16c
> >>>>>
> >>>>> [snip]
> >>>>>
> >>>>>> My quick fix is below.
> >>>>>>
> >>>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> >>>>>> index 5d81427..e587fbc 100644
> >>>>>> --- a/drivers/mmc/host/sh_mmcif.c
> >>>>>> +++ b/drivers/mmc/host/sh_mmcif.c
> >>>>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> >>>>>> *dev_id)
> >>>>>>   {
> >>>>>>          struct sh_mmcif_host *host = dev_id;
> >>>>>>          struct mmc_request *mrq = host->mrq;
> >>>>>> -       struct mmc_data *data = mrq->data;
> >>>>>> +       /*struct mmc_data *data = mrq->data; -- this cause null
> >>>>>> pointer access*/
> >>>>>> +       struct mmc_data *data;
> >>>>>> +
> >>>>>> +       /* quick fix by koba */
> >>>>>> +       if (mrq = NULL) {
> >>>>>> +               printk("sh_mmcif_irqt: mrq = NULL:
> >>>>>> host->wait_for=%d\n", host->wait_for);
> >>>>>> +       } else {
> >>>>>> +               data = mrq->data;
> >>>>>> +       }
> >>>>>>
> >>>>>>          cancel_delayed_work_sync(&host->timeout_work);
> >>>>>>
> >>>>>>
> >>>>>> With this patch, there is no null pointer accesses and got this log.
> >>>>>>
> >>>>>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
> >>>>>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
> >>>>>>    ...
> >>>>>>
> >>>>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
> >>>>>> There is code such like:
> >>>>>>
> >>>>>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
> >>>>>>         host->mrq = NULL;
> >>>>>>
> >>>>>> So, at the top of sh_mmcif_irqt, if host->wait_for =
> >>>>>> MMCIF_WAIT_FOR_REQUEST,
> >>>>>> host->mrq = NULL.
> >>>>>> It is too earlier to access mrq->data before checking host->mrq. it may
> >>>>>> cause null pointer access.
> >>>>>>
> >>>>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
> >>>>>
> >>>>> Thanks for your report and a fix. Could you please double-check, whether
> >>>>> the below patch also fixes your problem? Since such spurious interrupts
> >>>>> are possible I would commit a check like this one, but in the longer run
> >>>>> we want to identify and eliminate them, if possible. But since so far
> >>>>> these interrupts only happen on 1 board model and also not on all units
> >>>>> and not upon each boot, this could be a bit tricky.
> >>>>>
> >>>>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
> >>>>>
> >>>>> Thanks
> >>>>> Guennadi
> >>>>>
> >>>>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
> >>>>>   1 files changed, 2 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> >>>>> index 5d81427..82bf921 100644
> >>>>> --- a/drivers/mmc/host/sh_mmcif.c
> >>>>> +++ b/drivers/mmc/host/sh_mmcif.c
> >>>>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> >>>>> *dev_id)
> >>>>>   {
> >>>>>       struct sh_mmcif_host *host = dev_id;
> >>>>>       struct mmc_request *mrq = host->mrq;
> >>>>> -    struct mmc_data *data = mrq->data;
> >>>>>
> >>>>>       cancel_delayed_work_sync(&host->timeout_work);
> >>>>>
> >>>>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> >>>>> *dev_id)
> >>>>>       case MMCIF_WAIT_FOR_READ_END:
> >>>>>       case MMCIF_WAIT_FOR_WRITE_END:
> >>>>>           if (host->sd_error)
> >>>>> -            data->error = sh_mmcif_error_manage(host);
> >>>>> +            mrq->data->error = sh_mmcif_error_manage(host);
> >>>>>           break;
> >>>>>       default:
> >>>>>           BUG();
> >>>>>       }
> >>>>>
> >>>>>       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> >>>>> +        struct mmc_data *data = mrq->data;
> >>>>>           if (!mrq->cmd->error && data && !data->error)
> >>>>>               data->bytes_xfered > >>>>>                   data->blocks * data->blksz;
> >>>>>
> >>>>
> >>>> I tried this patch. It seems better.
> >>>> But I think this still have potential race condition.
> >>>> I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
> >>>> host->wait_for for new request at the same time.
> >>>> How about add this code at the top of sh_mmcif_irqt or before returning
> >>>> IRQ_WAKE_THREAD in sh_mmcif_intr ?
> >>>>
> >>>>      if (host->state = STATE_IDLE)
> >>>>          return IRQ_HANDLED;
> >>>>
> >>>> I will rebase my test environment to v3.6-rc3 or later. Then I will
> >>>> send you my .config.
> >>>>
> >>> How is this?
> >>> I hope this fixed in v3.6.
> >>
> >> Sorry, I still haven't come round to looking at this. I think, one thing 
> >> could halp, if you could try to find out what exactly those spurious 
> >> interrupts look like, i.e., what's their interrupt status? You could try 
> >> to print like
> >>
> >> diff -u a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> >> --- a/drivers/mmc/host/sh_mmcif.c
> >> +++ b/drivers/mmc/host/sh_mmcif.c
> >> @@ -1229,6 +1229,10 @@
> >>  		host->sd_error = true;
> >>  		dev_dbg(&host->pd->dev, "int err state = %08x\n", state);
> >>  	}
> >> +	if (host->state = STATE_IDLE) {
> >> +		dev_info(&host->pd->dev, "Spurious IRQ status 0x%x", state);
> >> +		return IRQ_HANDLED;
> >> +	}
> >>  	if (state & ~(INT_CMD12RBE | INT_CMD12CRE)) {
> >>  		if (!host->dma_active)
> >>  			return IRQ_WAKE_THREAD;
> >>
> >> Please, let me know, if it's not very easy for you ATM to perform the 
> >> test, I'll try to do it myself then.
> > 
> > OK. It is easy for me.
> > I got this log after mounting /dev/mmcblk2p1 (on eMMC) and executing
> > tar command to make file accesses.
> > This is based on v3.6-rc6.
> > 
> > [  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
> > [  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
> > [  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  221.585937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  222.039062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  222.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  222.382812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  223.109375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  223.406250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  223.734375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  223.750000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  224.398437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  230.289062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > 
> It might too earlier to report. I got this log.
> 
> [  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
> [  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
> [  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
...
> [  998.554687] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
...
> [ 1702.140625] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3800000
> [ 1702.148437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
...
> [ 1721.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3800000
> [ 1721.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
...
> [ 1934.296875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
...

So, I see 3 IRQ types there: auto CMD12 only (0x3000000), auto CMD12 with 
read completed (0x7400000), auto CMD12 with "Data Transmission Complete."

So, all of them are related to automatic CMD12 execution. I think, we 
should try to finc out now, how and when this auto CMD12 gets enabled, 
when it should be disabled again, and whether we have a problem with the 
logic there. Possibly, eMMC processing of CMD12 is different from normal 
MMC cards.

> After that, I tried the same thing without DMA by comment out like this.
> In this case spurious IRQ never occurred. 
> 
> diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board
> index 765f60a..d5e6609 100644
> --- a/arch/arm/mach-shmobile/board-kzm9g.c
> +++ b/arch/arm/mach-shmobile/board-kzm9g.c
> @@ -389,8 +389,8 @@ static struct resource sh_mmcif_resources[] = {
>  static struct sh_mmcif_plat_data sh_mmcif_platdata = {
>         .ocr            = MMC_VDD_165_195,
>         .caps           = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
> -       .slave_id_tx    = SHDMA_SLAVE_MMCIF_TX,
> -       .slave_id_rx    = SHDMA_SLAVE_MMCIF_RX,
> +       /*.slave_id_tx  = SHDMA_SLAVE_MMCIF_TX,*/
> +       /*.slave_id_rx  = SHDMA_SLAVE_MMCIF_RX,*/
>  };
> 
> 

Interesting. I don't so far see how this is related, but it's interesting 
to know.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Guennadi Liakhovetski]

On Tue, 18 Sep 2012, Tetsuyuki Kobayashi wrote:

> Hello Guennadi
> 
> (09/18/2012 05:02 PM), Tetsuyuki Kobayashi wrote:
> 
> >>>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
> >>>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> >>>>> interrupts without any active request. To prevent the Oops, that results
> >>>>> in such cases, don't dereference the mmc request pointer until we make
> >>>>> sure, that we are indeed processing such a request.
> >>>>>
> >>>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> >>>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> >>>>> ---
> >>>>>
> >>>>> Hello Kobayashi-san
> >>>>>
> >>>>> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
> >>>>>
> >>>>> ...
> >>>>>
> >>>>>> After applying this patch on kzm9g board, I got this error regarding
> >>>>>> eMMC.
> >>>>>> I think this is another problem.
> >>>>>>
> >>>>>>
> >>>>>> Unable to handle kernel NULL pointer dereference at virtual address
> >>>>>> 00000008
> >>>>>> pgd = c0004000
> >>>>>> [00000008] *pgd=00000000
> >>>>>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> >>>>>> Modules linked in:
> >>>>>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
> >>>>>> PC is at sh_mmcif_irqt+0x20/0xb30
> >>>>>> LR is at irq_thread+0x94/0x16c
> >>>>>
> >>>>> [snip]
> >>>>>
> >>>>>> My quick fix is below.
> >>>>>>
> >>>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> >>>>>> index 5d81427..e587fbc 100644
> >>>>>> --- a/drivers/mmc/host/sh_mmcif.c
> >>>>>> +++ b/drivers/mmc/host/sh_mmcif.c
> >>>>>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> >>>>>> *dev_id)
> >>>>>>   {
> >>>>>>          struct sh_mmcif_host *host = dev_id;
> >>>>>>          struct mmc_request *mrq = host->mrq;
> >>>>>> -       struct mmc_data *data = mrq->data;
> >>>>>> +       /*struct mmc_data *data = mrq->data; -- this cause null
> >>>>>> pointer access*/
> >>>>>> +       struct mmc_data *data;
> >>>>>> +
> >>>>>> +       /* quick fix by koba */
> >>>>>> +       if (mrq == NULL) {
> >>>>>> +               printk("sh_mmcif_irqt: mrq == NULL:
> >>>>>> host->wait_for=%d\n", host->wait_for);
> >>>>>> +       } else {
> >>>>>> +               data = mrq->data;
> >>>>>> +       }
> >>>>>>
> >>>>>>          cancel_delayed_work_sync(&host->timeout_work);
> >>>>>>
> >>>>>>
> >>>>>> With this patch, there is no null pointer accesses and got this log.
> >>>>>>
> >>>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
> >>>>>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
> >>>>>>    ...
> >>>>>>
> >>>>>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
> >>>>>> There is code such like:
> >>>>>>
> >>>>>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
> >>>>>>         host->mrq = NULL;
> >>>>>>
> >>>>>> So, at the top of sh_mmcif_irqt, if host->wait_for ==
> >>>>>> MMCIF_WAIT_FOR_REQUEST,
> >>>>>> host->mrq = NULL.
> >>>>>> It is too earlier to access mrq->data before checking host->mrq. it may
> >>>>>> cause null pointer access.
> >>>>>>
> >>>>>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
> >>>>>
> >>>>> Thanks for your report and a fix. Could you please double-check, whether
> >>>>> the below patch also fixes your problem? Since such spurious interrupts
> >>>>> are possible I would commit a check like this one, but in the longer run
> >>>>> we want to identify and eliminate them, if possible. But since so far
> >>>>> these interrupts only happen on 1 board model and also not on all units
> >>>>> and not upon each boot, this could be a bit tricky.
> >>>>>
> >>>>> One more question - is this only needed for 3.7 or also for 3.6 / stable?
> >>>>>
> >>>>> Thanks
> >>>>> Guennadi
> >>>>>
> >>>>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
> >>>>>   1 files changed, 2 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> >>>>> index 5d81427..82bf921 100644
> >>>>> --- a/drivers/mmc/host/sh_mmcif.c
> >>>>> +++ b/drivers/mmc/host/sh_mmcif.c
> >>>>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> >>>>> *dev_id)
> >>>>>   {
> >>>>>       struct sh_mmcif_host *host = dev_id;
> >>>>>       struct mmc_request *mrq = host->mrq;
> >>>>> -    struct mmc_data *data = mrq->data;
> >>>>>
> >>>>>       cancel_delayed_work_sync(&host->timeout_work);
> >>>>>
> >>>>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> >>>>> *dev_id)
> >>>>>       case MMCIF_WAIT_FOR_READ_END:
> >>>>>       case MMCIF_WAIT_FOR_WRITE_END:
> >>>>>           if (host->sd_error)
> >>>>> -            data->error = sh_mmcif_error_manage(host);
> >>>>> +            mrq->data->error = sh_mmcif_error_manage(host);
> >>>>>           break;
> >>>>>       default:
> >>>>>           BUG();
> >>>>>       }
> >>>>>
> >>>>>       if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> >>>>> +        struct mmc_data *data = mrq->data;
> >>>>>           if (!mrq->cmd->error && data && !data->error)
> >>>>>               data->bytes_xfered =
> >>>>>                   data->blocks * data->blksz;
> >>>>>
> >>>>
> >>>> I tried this patch. It seems better.
> >>>> But I think this still have potential race condition.
> >>>> I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
> >>>> host->wait_for for new request at the same time.
> >>>> How about add this code at the top of sh_mmcif_irqt or before returning
> >>>> IRQ_WAKE_THREAD in sh_mmcif_intr ?
> >>>>
> >>>>      if (host->state == STATE_IDLE)
> >>>>          return IRQ_HANDLED;
> >>>>
> >>>> I will rebase my test environment to v3.6-rc3 or later. Then I will
> >>>> send you my .config.
> >>>>
> >>> How is this?
> >>> I hope this fixed in v3.6.
> >>
> >> Sorry, I still haven't come round to looking at this. I think, one thing 
> >> could halp, if you could try to find out what exactly those spurious 
> >> interrupts look like, i.e., what's their interrupt status? You could try 
> >> to print like
> >>
> >> diff -u a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> >> --- a/drivers/mmc/host/sh_mmcif.c
> >> +++ b/drivers/mmc/host/sh_mmcif.c
> >> @@ -1229,6 +1229,10 @@
> >>  		host->sd_error = true;
> >>  		dev_dbg(&host->pd->dev, "int err state = %08x\n", state);
> >>  	}
> >> +	if (host->state == STATE_IDLE) {
> >> +		dev_info(&host->pd->dev, "Spurious IRQ status 0x%x", state);
> >> +		return IRQ_HANDLED;
> >> +	}
> >>  	if (state & ~(INT_CMD12RBE | INT_CMD12CRE)) {
> >>  		if (!host->dma_active)
> >>  			return IRQ_WAKE_THREAD;
> >>
> >> Please, let me know, if it's not very easy for you ATM to perform the 
> >> test, I'll try to do it myself then.
> > 
> > OK. It is easy for me.
> > I got this log after mounting /dev/mmcblk2p1 (on eMMC) and executing
> > tar command to make file accesses.
> > This is based on v3.6-rc6.
> > 
> > [  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
> > [  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
> > [  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  221.585937] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  222.039062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  222.226562] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  222.382812] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  223.109375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  223.406250] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  223.734375] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  223.750000] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  224.398437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > [  230.289062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
> > 
> It might too earlier to report. I got this log.
> 
> [  149.968750] EXT4-fs (mmcblk2p1): warning: maximal mount count reached, running e2fsck is recommended
> [  150.296875] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
> [  221.539062] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
...
> [  998.554687] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
...
> [ 1702.140625] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3800000
> [ 1702.148437] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
...
> [ 1721.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3800000
> [ 1721.171875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x3000000
...
> [ 1934.296875] sh_mmcif sh_mmcif.0: Spurious IRQ status 0x7400000
...

So, I see 3 IRQ types there: auto CMD12 only (0x3000000), auto CMD12 with 
read completed (0x7400000), auto CMD12 with "Data Transmission Complete."

So, all of them are related to automatic CMD12 execution. I think, we 
should try to finc out now, how and when this auto CMD12 gets enabled, 
when it should be disabled again, and whether we have a problem with the 
logic there. Possibly, eMMC processing of CMD12 is different from normal 
MMC cards.

> After that, I tried the same thing without DMA by comment out like this.
> In this case spurious IRQ never occurred. 
> 
> diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board
> index 765f60a..d5e6609 100644
> --- a/arch/arm/mach-shmobile/board-kzm9g.c
> +++ b/arch/arm/mach-shmobile/board-kzm9g.c
> @@ -389,8 +389,8 @@ static struct resource sh_mmcif_resources[] = {
>  static struct sh_mmcif_plat_data sh_mmcif_platdata = {
>         .ocr            = MMC_VDD_165_195,
>         .caps           = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
> -       .slave_id_tx    = SHDMA_SLAVE_MMCIF_TX,
> -       .slave_id_rx    = SHDMA_SLAVE_MMCIF_RX,
> +       /*.slave_id_tx  = SHDMA_SLAVE_MMCIF_TX,*/
> +       /*.slave_id_rx  = SHDMA_SLAVE_MMCIF_RX,*/
>  };
> 
> 

Interesting. I don't so far see how this is related, but it's interesting 
to know.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

(2012/08/22 15:49), Guennadi Liakhovetski wrote:
> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> interrupts without any active request. To prevent the Oops, that results
> in such cases, don't dereference the mmc request pointer until we make
> sure, that we are indeed processing such a request.
>
> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

I verified on kzm9g.
This works with
[PATCH] mmc: sh-mmcif: properly handle MMC_WRITE_MULTIPLE_BLOCK 
completion IRQ

Tested-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>

> ---
>
> Hello Kobayashi-san
>
> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>
> ...
>
>> After applying this patch on kzm9g board, I got this error regarding eMMC.
>> I think this is another problem.
>>
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 00000008
>> pgd = c0004000
>> [00000008] *pgd\0000000
>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> Modules linked in:
>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>> PC is at sh_mmcif_irqt+0x20/0xb30
>> LR is at irq_thread+0x94/0x16c
>
> [snip]
>
>> My quick fix is below.
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..e587fbc 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   {
>>          struct sh_mmcif_host *host = dev_id;
>>          struct mmc_request *mrq = host->mrq;
>> -       struct mmc_data *data = mrq->data;
>> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer access*/
>> +       struct mmc_data *data;
>> +
>> +       /* quick fix by koba */
>> +       if (mrq = NULL) {
>> +               printk("sh_mmcif_irqt: mrq = NULL: host->wait_for=%d\n", host->wait_for);
>> +       } else {
>> +               data = mrq->data;
>> +       }
>>
>>          cancel_delayed_work_sync(&host->timeout_work);
>>
>>
>> With this patch, there is no null pointer accesses and got this log.
>>
>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>> sh_mmcif_irqt: mrq = NULL: host->wait_for=0
>>    ...
>>
>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>> There is code such like:
>>
>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>         host->mrq = NULL;
>>
>> So, at the top of sh_mmcif_irqt, if host->wait_for = MMCIF_WAIT_FOR_REQUEST,
>> host->mrq = NULL.
>> It is too earlier to access mrq->data before checking host->mrq. it may
>> cause null pointer access.
>>
>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>
> Thanks for your report and a fix. Could you please double-check, whether
> the below patch also fixes your problem? Since such spurious interrupts
> are possible I would commit a check like this one, but in the longer run
> we want to identify and eliminate them, if possible. But since so far
> these interrupts only happen on 1 board model and also not on all units
> and not upon each boot, this could be a bit tricky.
>
> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>
> Thanks
> Guennadi
>
>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 5d81427..82bf921 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   {
>   	struct sh_mmcif_host *host = dev_id;
>   	struct mmc_request *mrq = host->mrq;
> -	struct mmc_data *data = mrq->data;
>
>   	cancel_delayed_work_sync(&host->timeout_work);
>
> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   	case MMCIF_WAIT_FOR_READ_END:
>   	case MMCIF_WAIT_FOR_WRITE_END:
>   		if (host->sd_error)
> -			data->error = sh_mmcif_error_manage(host);
> +			mrq->data->error = sh_mmcif_error_manage(host);
>   		break;
>   	default:
>   		BUG();
>   	}
>
>   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> +		struct mmc_data *data = mrq->data;
>   		if (!mrq->cmd->error && data && !data->error)
>   			data->bytes_xfered >   				data->blocks * data->blksz;
>

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

(2012/08/22 15:49), Guennadi Liakhovetski wrote:
> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> interrupts without any active request. To prevent the Oops, that results
> in such cases, don't dereference the mmc request pointer until we make
> sure, that we are indeed processing such a request.
>
> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

I verified on kzm9g.
This works with
[PATCH] mmc: sh-mmcif: properly handle MMC_WRITE_MULTIPLE_BLOCK 
completion IRQ

Tested-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>

> ---
>
> Hello Kobayashi-san
>
> On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
>
> ...
>
>> After applying this patch on kzm9g board, I got this error regarding eMMC.
>> I think this is another problem.
>>
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 00000008
>> pgd = c0004000
>> [00000008] *pgd=00000000
>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> Modules linked in:
>> CPU: 1    Not tainted  (3.6.0-rc2+ #103)
>> PC is at sh_mmcif_irqt+0x20/0xb30
>> LR is at irq_thread+0x94/0x16c
>
> [snip]
>
>> My quick fix is below.
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..e587fbc 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   {
>>          struct sh_mmcif_host *host = dev_id;
>>          struct mmc_request *mrq = host->mrq;
>> -       struct mmc_data *data = mrq->data;
>> +       /*struct mmc_data *data = mrq->data; -- this cause null pointer access*/
>> +       struct mmc_data *data;
>> +
>> +       /* quick fix by koba */
>> +       if (mrq == NULL) {
>> +               printk("sh_mmcif_irqt: mrq == NULL: host->wait_for=%d\n", host->wait_for);
>> +       } else {
>> +               data = mrq->data;
>> +       }
>>
>>          cancel_delayed_work_sync(&host->timeout_work);
>>
>>
>> With this patch, there is no null pointer accesses and got this log.
>>
>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>> sh_mmcif_irqt: mrq == NULL: host->wait_for=0
>>    ...
>>
>> host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
>> There is code such like:
>>
>>         host->wait_for = MMCIF_WAIT_FOR_REQUEST;
>>         host->mrq = NULL;
>>
>> So, at the top of sh_mmcif_irqt, if host->wait_for == MMCIF_WAIT_FOR_REQUEST,
>> host->mrq = NULL.
>> It is too earlier to access mrq->data before checking host->mrq. it may
>> cause null pointer access.
>>
>> Goda-san, could you check this and refine the code of sh_mmcif_irqt?
>
> Thanks for your report and a fix. Could you please double-check, whether
> the below patch also fixes your problem? Since such spurious interrupts
> are possible I would commit a check like this one, but in the longer run
> we want to identify and eliminate them, if possible. But since so far
> these interrupts only happen on 1 board model and also not on all units
> and not upon each boot, this could be a bit tricky.
>
> One more question - is this only needed for 3.7 or also for 3.6 / stable?
>
> Thanks
> Guennadi
>
>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 5d81427..82bf921 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   {
>   	struct sh_mmcif_host *host = dev_id;
>   	struct mmc_request *mrq = host->mrq;
> -	struct mmc_data *data = mrq->data;
>
>   	cancel_delayed_work_sync(&host->timeout_work);
>
> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>   	case MMCIF_WAIT_FOR_READ_END:
>   	case MMCIF_WAIT_FOR_WRITE_END:
>   		if (host->sd_error)
> -			data->error = sh_mmcif_error_manage(host);
> +			mrq->data->error = sh_mmcif_error_manage(host);
>   		break;
>   	default:
>   		BUG();
>   	}
>
>   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> +		struct mmc_data *data = mrq->data;
>   		if (!mrq->cmd->error && data && !data->error)
>   			data->bytes_xfered =
>   				data->blocks * data->blksz;
>

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Dear linux-mmc maintainer,

(09/19/2012 11:50 AM), Tetsuyuki Kobayashi wrote:
> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>> interrupts without any active request. To prevent the Oops, that results
>> in such cases, don't dereference the mmc request pointer until we make
>> sure, that we are indeed processing such a request.
>>
>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> 
> I verified on kzm9g.
> This works with
> [PATCH] mmc: sh-mmcif: properly handle MMC_WRITE_MULTIPLE_BLOCK 
> completion IRQ
> 
> Tested-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> 
>> ---
[snip]
>>
>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..82bf921 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   {
>>   	struct sh_mmcif_host *host = dev_id;
>>   	struct mmc_request *mrq = host->mrq;
>> -	struct mmc_data *data = mrq->data;
>>
>>   	cancel_delayed_work_sync(&host->timeout_work);
>>
>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   	case MMCIF_WAIT_FOR_READ_END:
>>   	case MMCIF_WAIT_FOR_WRITE_END:
>>   		if (host->sd_error)
>> -			data->error = sh_mmcif_error_manage(host);
>> +			mrq->data->error = sh_mmcif_error_manage(host);
>>   		break;
>>   	default:
>>   		BUG();
>>   	}
>>
>>   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>> +		struct mmc_data *data = mrq->data;
>>   		if (!mrq->cmd->error && data && !data->error)
>>   			data->bytes_xfered >>   				data->blocks * data->blksz;
>>
> 

Without this patch, the following Oops occurs. (kzm9g on v3.6-rc7)
Please push this to v3.6, not only 3.7-next.


[   20.273437] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[   20.281250] pgd = c0004000
[   20.281250] [00000008] *pgd\0000000
[   20.281250] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[   20.281250] Modules linked in:
[   20.281250] CPU: 1    Not tainted  (3.6.0-rc7 #28)
[   20.281250] PC is at sh_mmcif_irqt+0x18/0xb1c
[   20.281250] LR is at irq_thread+0x90/0x15c
[   20.281250] pc : [<c0250250>]    lr : [<c005f180>]    psr: 60000113
[   20.281250] sp : de23df58  ip : 00000000  fp : 00000000
[   20.281250] r10: 00000000  r9 : de1dcab4  r8 : dd9f6360
[   20.281250] r7 : de23c000  r6 : de23c000  r5 : 00000000  r4 : de1dca80
[   20.281250] r3 : c0250238  r2 : 00000000  r1 : de1dca80  r0 : de1dcab4
[   20.281250] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   20.281250] Control: 10c5387d  Table: 5eb4804a  DAC: 00000015
[   20.281250] Process irq/173-sh_mmc: (pid: 406, stack limit = 0xde23c2f0)
[   20.281250] Stack: (0xde23df58 to 0xde23e000)
[   20.281250] df40:                                                       00000003 00000000
[   20.281250] df60: c0331f6c de1dca80 c046634c c0468190 dd9ca800 00000001 00000000 dd9f6340
[   20.281250] df80: de00bc40 de23c000 de23c000 dd9f6360 00000000 00000000 00000000 c005f180
[   20.281250] dfa0: 00000000 de23dfa4 c005f02c de043e3c dd9f6340 de043e3c dd9f6340 c005f0f0
[   20.281250] dfc0: 00000013 00000000 00000000 c00387ac 00000000 dd9f6340 00000000 00000000
[   20.281250] dfe0: de23dfe0 de23dfe0 de043e3c c0038728 c000f178 c000f178 00000000 00000000
[   20.281250] [<c0250250>] (sh_mmcif_irqt+0x18/0xb1c) from [<c005f180>] (irq_thread+0x90/0x15c)
[   20.281250] [<c005f180>] (irq_thread+0x90/0x15c) from [<c00387ac>] (kthread+0x84/0x90)
[   20.281250] [<c00387ac>] (kthread+0x84/0x90) from [<c000f178>] (kernel_thread_exit+0x0/0x8)
[   20.281250] Code: e5915004 e1a04001 e24dd024 e1a00009 (e595a008)
[   20.281250] ---[ end trace 6efe730b0884a251 ]---

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Dear linux-mmc maintainer,

(09/19/2012 11:50 AM), Tetsuyuki Kobayashi wrote:
> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>> interrupts without any active request. To prevent the Oops, that results
>> in such cases, don't dereference the mmc request pointer until we make
>> sure, that we are indeed processing such a request.
>>
>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> 
> I verified on kzm9g.
> This works with
> [PATCH] mmc: sh-mmcif: properly handle MMC_WRITE_MULTIPLE_BLOCK 
> completion IRQ
> 
> Tested-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> 
>> ---
[snip]
>>
>>   drivers/mmc/host/sh_mmcif.c |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
>> index 5d81427..82bf921 100644
>> --- a/drivers/mmc/host/sh_mmcif.c
>> +++ b/drivers/mmc/host/sh_mmcif.c
>> @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   {
>>   	struct sh_mmcif_host *host = dev_id;
>>   	struct mmc_request *mrq = host->mrq;
>> -	struct mmc_data *data = mrq->data;
>>
>>   	cancel_delayed_work_sync(&host->timeout_work);
>>
>> @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>>   	case MMCIF_WAIT_FOR_READ_END:
>>   	case MMCIF_WAIT_FOR_WRITE_END:
>>   		if (host->sd_error)
>> -			data->error = sh_mmcif_error_manage(host);
>> +			mrq->data->error = sh_mmcif_error_manage(host);
>>   		break;
>>   	default:
>>   		BUG();
>>   	}
>>
>>   	if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
>> +		struct mmc_data *data = mrq->data;
>>   		if (!mrq->cmd->error && data && !data->error)
>>   			data->bytes_xfered =
>>   				data->blocks * data->blksz;
>>
> 

Without this patch, the following Oops occurs. (kzm9g on v3.6-rc7)
Please push this to v3.6, not only 3.7-next.


[   20.273437] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[   20.281250] pgd = c0004000
[   20.281250] [00000008] *pgd=00000000
[   20.281250] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[   20.281250] Modules linked in:
[   20.281250] CPU: 1    Not tainted  (3.6.0-rc7 #28)
[   20.281250] PC is at sh_mmcif_irqt+0x18/0xb1c
[   20.281250] LR is at irq_thread+0x90/0x15c
[   20.281250] pc : [<c0250250>]    lr : [<c005f180>]    psr: 60000113
[   20.281250] sp : de23df58  ip : 00000000  fp : 00000000
[   20.281250] r10: 00000000  r9 : de1dcab4  r8 : dd9f6360
[   20.281250] r7 : de23c000  r6 : de23c000  r5 : 00000000  r4 : de1dca80
[   20.281250] r3 : c0250238  r2 : 00000000  r1 : de1dca80  r0 : de1dcab4
[   20.281250] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   20.281250] Control: 10c5387d  Table: 5eb4804a  DAC: 00000015
[   20.281250] Process irq/173-sh_mmc: (pid: 406, stack limit = 0xde23c2f0)
[   20.281250] Stack: (0xde23df58 to 0xde23e000)
[   20.281250] df40:                                                       00000003 00000000
[   20.281250] df60: c0331f6c de1dca80 c046634c c0468190 dd9ca800 00000001 00000000 dd9f6340
[   20.281250] df80: de00bc40 de23c000 de23c000 dd9f6360 00000000 00000000 00000000 c005f180
[   20.281250] dfa0: 00000000 de23dfa4 c005f02c de043e3c dd9f6340 de043e3c dd9f6340 c005f0f0
[   20.281250] dfc0: 00000013 00000000 00000000 c00387ac 00000000 dd9f6340 00000000 00000000
[   20.281250] dfe0: de23dfe0 de23dfe0 de043e3c c0038728 c000f178 c000f178 00000000 00000000
[   20.281250] [<c0250250>] (sh_mmcif_irqt+0x18/0xb1c) from [<c005f180>] (irq_thread+0x90/0x15c)
[   20.281250] [<c005f180>] (irq_thread+0x90/0x15c) from [<c00387ac>] (kthread+0x84/0x90)
[   20.281250] [<c00387ac>] (kthread+0x84/0x90) from [<c000f178>] (kernel_thread_exit+0x0/0x8)
[   20.281250] Code: e5915004 e1a04001 e24dd024 e1a00009 (e595a008)
[   20.281250] ---[ end trace 6efe730b0884a251 ]---

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Chris Ball]

Hi Kobayashi,

On Tue, Sep 25 2012, Tetsuyuki Kobayashi wrote:
> (09/19/2012 11:50 AM), Tetsuyuki Kobayashi wrote:
>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>>> interrupts without any active request. To prevent the Oops, that results
>>> in such cases, don't dereference the mmc request pointer until we make
>>> sure, that we are indeed processing such a request.
>>>
>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> 
>> I verified on kzm9g.
>> This works with
>> [PATCH] mmc: sh-mmcif: properly handle MMC_WRITE_MULTIPLE_BLOCK 
>> completion IRQ
>> 
>> Tested-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>
> Without this patch, the following Oops occurs. (kzm9g on v3.6-rc7)
> Please push this to v3.6, not only 3.7-next.

I'm traveling from Shanghai to Boston (home) at the moment, so I can't
push this immediately.  I'll either get it into 3.6, or 3.7 with a tag
for 3.6-stable.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Chris Ball]

Hi Kobayashi,

On Tue, Sep 25 2012, Tetsuyuki Kobayashi wrote:
> (09/19/2012 11:50 AM), Tetsuyuki Kobayashi wrote:
>> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>>> interrupts without any active request. To prevent the Oops, that results
>>> in such cases, don't dereference the mmc request pointer until we make
>>> sure, that we are indeed processing such a request.
>>>
>>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> 
>> I verified on kzm9g.
>> This works with
>> [PATCH] mmc: sh-mmcif: properly handle MMC_WRITE_MULTIPLE_BLOCK 
>> completion IRQ
>> 
>> Tested-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>
> Without this patch, the following Oops occurs. (kzm9g on v3.6-rc7)
> Please push this to v3.6, not only 3.7-next.

I'm traveling from Shanghai to Boston (home) at the moment, so I can't
push this immediately.  I'll either get it into 3.6, or 3.7 with a tag
for 3.6-stable.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Chris Ball]

Hi,

On Wed, Aug 22 2012, Guennadi Liakhovetski wrote:
> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious 
> interrupts without any active request. To prevent the Oops, that results 
> in such cases, don't dereference the mmc request pointer until we make 
> sure, that we are indeed processing such a request.
>
> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

Thanks, pushed to mmc-next for 3.7.

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Chris Ball]

Hi,

On Wed, Aug 22 2012, Guennadi Liakhovetski wrote:
> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious 
> interrupts without any active request. To prevent the Oops, that results 
> in such cases, don't dereference the mmc request pointer until we make 
> sure, that we are indeed processing such a request.
>
> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

Thanks, pushed to mmc-next for 3.7.

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello, Chris

(2012/09/19 15:24), Chris Ball wrote:
> Hi,
> 
> On Wed, Aug 22 2012, Guennadi Liakhovetski wrote:
>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>> interrupts without any active request. To prevent the Oops, that results
>> in such cases, don't dereference the mmc request pointer until we make
>> sure, that we are indeed processing such a request.
>>
>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> 
> Thanks, pushed to mmc-next for 3.7.

It needs this patch for kzm9g board to boot kernel 3.6-rc6 successfully.
Can I ask you to queue this patch for 3.6-rc7 ?

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello, Chris

(2012/09/19 15:24), Chris Ball wrote:
> Hi,
> 
> On Wed, Aug 22 2012, Guennadi Liakhovetski wrote:
>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>> interrupts without any active request. To prevent the Oops, that results
>> in such cases, don't dereference the mmc request pointer until we make
>> sure, that we are indeed processing such a request.
>>
>> Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> 
> Thanks, pushed to mmc-next for 3.7.

It needs this patch for kzm9g board to boot kernel 3.6-rc6 successfully.
Can I ask you to queue this patch for 3.6-rc7 ?

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Magnus Damm]

Hi Paul,

On Mon, Aug 20, 2012 at 2:24 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Sun, Aug 19, 2012 at 09:45:33PM -0700, Kuninori Morimoto wrote:
>>
>> Hi Paul
>> Cc Magnus, Kobayashi-san
>>
>> > > irq: irq_domain_associate_many(<no-node>, irqbaseT5, hwbaseT5, count=1)
>> > > irq: irq_domain_associate_many(<no-node>, irqbaseT6, hwbaseT6, count=1)
>> > > irq: irq_domain_associate_many(<no-node>, irqbaseT7, hwbaseT7, count=1)
>> > > irq: irq_domain_associate_many(<no-node>, irqbaseT8, hwbaseT8, count=1)
>> > > irq: irq_domain_associate_many(<no-node>, irqbaseT9, hwbaseT9, count=1)
>> > > irq: irq_domain_associate_many(<no-node>, irqbaseU0, hwbaseU0, count=1)
>> > > irq: irq_domain_associate_many(<no-node>, irqbaseU1, hwbaseU1, count=1)
>> > > irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)
>> > > ------------[ cut here ]------------
>> > > WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
>> > > error: irq_desc already associated; irqU2 hwirq=0x228
>> >
>> > Well, that's certainly a valid bug. hwirq 552 is already bound to the
>> > previous controller, and the vector in question is being registered a
>> > second time under another controller. This looks to be RTDMAC_2_DEI6 (0x1300),
>> > but the rest descends in to macro hell, so it's not obvious why the same
>> > vector is being registered in multiple places.
>>
>>
>> I'm not sure why, but this patch solved problem ?
>>
> I'll let Magnus figure this one out, as it was his hack in the first
> place. At least we know the irqdomain code isn't at fault anymore.

Well, I'm quite certain it didn't trigger before the INTC code got
this recent upgrade. Or did it fail silently? I wonder why we have to
bump up the relocation base all of a sudden? Last time I checked I had
to revert two of your most recent commits to get the sh73a0 based
board to even boot with upstream. I believe this is the same issue
that Kobayashi-san and Morimoto-san have been talking about.

Anyway, as I'm sure you've noticed, I put a sh7273 based board next to
the H1 board a few weeks ago. I can also provide you with a sh73a0
board if that would help. Please let me know if there is anything else
you need.

Thanks,

/ magnus

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Paul Mundt]

On Mon, Aug 20, 2012 at 04:18:48PM +0900, Magnus Damm wrote:
> On Mon, Aug 20, 2012 at 2:24 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Sun, Aug 19, 2012 at 09:45:33PM -0700, Kuninori Morimoto wrote:
> >> > > irq: irq_domain_associate_many(<no-node>, irqbaseT5, hwbaseT5, count=1)
> >> > > irq: irq_domain_associate_many(<no-node>, irqbaseT6, hwbaseT6, count=1)
> >> > > irq: irq_domain_associate_many(<no-node>, irqbaseT7, hwbaseT7, count=1)
> >> > > irq: irq_domain_associate_many(<no-node>, irqbaseT8, hwbaseT8, count=1)
> >> > > irq: irq_domain_associate_many(<no-node>, irqbaseT9, hwbaseT9, count=1)
> >> > > irq: irq_domain_associate_many(<no-node>, irqbaseU0, hwbaseU0, count=1)
> >> > > irq: irq_domain_associate_many(<no-node>, irqbaseU1, hwbaseU1, count=1)
> >> > > irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)
> >> > > ------------[ cut here ]------------
> >> > > WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
> >> > > error: irq_desc already associated; irqU2 hwirq=0x228
> >> >
> >> > Well, that's certainly a valid bug. hwirq 552 is already bound to the
> >> > previous controller, and the vector in question is being registered a
> >> > second time under another controller. This looks to be RTDMAC_2_DEI6 (0x1300),
> >> > but the rest descends in to macro hell, so it's not obvious why the same
> >> > vector is being registered in multiple places.
> >>
> >>
> >> I'm not sure why, but this patch solved problem ?
> >>
> > I'll let Magnus figure this one out, as it was his hack in the first
> > place. At least we know the irqdomain code isn't at fault anymore.
> 
> Well, I'm quite certain it didn't trigger before the INTC code got
> this recent upgrade. Or did it fail silently? I wonder why we have to
> bump up the relocation base all of a sudden?

It was broken before, the second controller was simply trampling the
first one by way of the -EEXIST case from irq_alloc_desc_at(). The
irqdomain code has simply tightened down the sanity checks and error
path.

I have no idea what you intend to do with the relocation base, but it's
certainly not valid to have the same IRQ for multiple controllers.

> Last time I checked I had to revert two of your most recent commits to
> get the sh73a0 based board to even boot with upstream. I believe this
> is the same issue that Kobayashi-san and Morimoto-san have been talking
> about.
> 
Which have subsequently all been fixed. This issue is unrelated.

> Anyway, as I'm sure you've noticed, I put a sh7273 based board next to
> the H1 board a few weeks ago. I can also provide you with a sh73a0
> board if that would help. Please let me know if there is anything else
> you need.
> 
I don't intend to wade through the macro hell that you and Rafael
introduced to figure out why a definition is being repeated. I prefer to
avoid macro hell largely because it makes debugging things like this a
complete and utter nightmare.

You're free to ignore the warning until that gets sorted out, as it's not
fatal. As it stands sh73a0 is doing something bogus with its registration
that needs to be identified and corrected, unrelated to irqdomains.

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Kuninori Morimoto]

Hi Paul
Cc Magnus

> > > place. At least we know the irqdomain code isn't at fault anymore.

I tried show irq number on "non-irqdomain kernel" and "irqdomain kernel".
And compared these 2 kernel irq table.
("irqdomain kernel" doesn't have my quick hack patch => got WARNING)

It were
	register_intc_controller(&intcs_desc);
	register_intc_controller(&intca_irq_pins_desc);
	register_intc_controller(&intc_pint0_desc);
	register_intc_controller(&intc_pint1_desc);

1st register_intc_controller()'s irq were
	irqdomain	: from 448 to 680
        non-irqdomain	: from 448 to 680
2nd register_intc_controller()'s irq were
	irqdomain	: from 560 to 959 <        non-irqdomain	: from 544 to 943 <3rd register_intc_controller()'s irq were
	irqdomain	: from 700 to 731
        non-irqdomain	: from 700 to 731
4th register_intc_controller()'s irq were
	irqdomain	: from 732 to 739
        non-irqdomain	: from 732 to 739

2nd register_intc_controller() mapped irq to strange area.

Best regards
---
Kuninori Morimoto

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Paul Mundt]

On Mon, Aug 20, 2012 at 12:41:28AM -0700, Kuninori Morimoto wrote:
> 
> Hi Paul
> Cc Magnus
> 
> > > > place. At least we know the irqdomain code isn't at fault anymore.
> 
> I tried show irq number on "non-irqdomain kernel" and "irqdomain kernel".
> And compared these 2 kernel irq table.
> ("irqdomain kernel" doesn't have my quick hack patch => got WARNING)
> 
> It were
> 	register_intc_controller(&intcs_desc);
> 	register_intc_controller(&intca_irq_pins_desc);
> 	register_intc_controller(&intc_pint0_desc);
> 	register_intc_controller(&intc_pint1_desc);
> 
> 1st register_intc_controller()'s irq were
> 	irqdomain	: from 448 to 680
>         non-irqdomain	: from 448 to 680
> 2nd register_intc_controller()'s irq were
> 	irqdomain	: from 560 to 959 <>         non-irqdomain	: from 544 to 943 <
How are you getting these ranges?

The irqdomain ranges are calculated using evt2irq(), but it looks like
sh73a0 needs to use intcs_evt2irq()/to_intc_vect() for factoring in the
offsets. That offset factorization appears to be what is throwing this
out of range -- though why evt2irq() use on these vectors hasn't resulted
in issues before this I don't know.

Do you observe any difference by dropping evt2irq() bounding for the
linear range and simply using the tree type?

---

diff --git a/drivers/sh/intc/irqdomain.c b/drivers/sh/intc/irqdomain.c
index 3968f1c..5ba8ba7 100644
--- a/drivers/sh/intc/irqdomain.c
+++ b/drivers/sh/intc/irqdomain.c
@@ -44,6 +44,7 @@ static const struct irq_domain_ops intc_evt_ops = {
 void __init intc_irq_domain_init(struct intc_desc_int *d,
 				 struct intc_hw_desc *hw)
 {
+#if 0
 	unsigned int irq_base, irq_end;
 
 	/*
@@ -62,6 +63,7 @@ void __init intc_irq_domain_init(struct intc_desc_int *d,
 		d->domain = irq_domain_add_linear(NULL, hw->nr_vectors,
 						  &intc_evt_ops, NULL);
 	else
+#endif
 		d->domain = irq_domain_add_tree(NULL, &intc_evt_ops, NULL);
 
 	BUG_ON(!d->domain);

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Kuninori Morimoto]

Hi Paul

> The irqdomain ranges are calculated using evt2irq(), but it looks like
> sh73a0 needs to use intcs_evt2irq()/to_intc_vect() for factoring in the
> offsets. That offset factorization appears to be what is throwing this
> out of range -- though why evt2irq() use on these vectors hasn't resulted
> in issues before this I don't know.
>
> Do you observe any difference by dropping evt2irq() bounding for the
> linear range and simply using the tree type?

I tried your patch, but I got same result as before.
I'm using 
 linus/master + paul/sh-latest + your-patch

----------------
irq: irq_domain_associate_many(<no-node>, irqbaseQ6, hwbaseQ6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseQ7, hwbaseQ7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseQ8, hwbaseQ8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR0, hwbaseR0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR1, hwbaseR1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR2, hwbaseR2, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseR3, hwbaseR3, count=1)
(snip)
intc: Registered controller 'sh73a0-intca-irq-pins' with 32 IRQs
irq: Allocated domain of type 3 @0xde8029c0
irq: irq_domain_associate_many(<no-node>, irqbaseT4, hwbaseT4, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseT5, hwbaseT5, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseT6, hwbaseT6, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseT7, hwbaseT7, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseT8, hwbaseT8, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseT9, hwbaseT9, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseU0, hwbaseU0, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseU1, hwbaseU1, count=1)
irq: irq_domain_associate_many(<no-node>, irqbaseU2, hwbaseU2, count=1)
------------[ cut here ]------------
WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
error: irq_desc already associated; irqU2 hwirq=0x228
Modules linked in:
Backtrace:
[<c0012358>] (dump_backtrace+0x0/0x10c) from [<c02e7e1c>] (dump_stack+0x18/0x1c)
 r6:c0065640 r5:00000009 r4:c03e9ed8 r3:c0404908
[<c02e7e04>] (dump_stack+0x0/0x1c) from [<c001cecc>] (warn_slowpath_common+0x54)
[<c001ce78>] (warn_slowpath_common+0x0/0x6c) from [<c001cf88>] (warn_slowpath_f)
 r8:00000228 r7:c03de514 r6:00000228 r5:00000000 r4:de8029c0
r3:00000009

Best regards
---
Kuninori Morimoto

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Kuninori Morimoto]

Hi

> > 1st register_intc_controller()'s irq were
> > 	irqdomain	: from 448 to 680
> >         non-irqdomain	: from 448 to 680
> > 2nd register_intc_controller()'s irq were
> > 	irqdomain	: from 560 to 959 <> >         non-irqdomain	: from 544 to 943 <> 
> How are you getting these ranges?

Grr. I'm so sorry.
It was my fault.
Above 2nd irqdomain kernel had my quick hack patch.
I double checked irq ranges, and both kernel had same ranges.

I'm so sorry again

Best regards
---
Kuninori Morimoto

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Kuninori Morimoto]

Hi Kobayashi-san

> After applying this patch on kzm9g board, I got this error regarding eMMC.
> I think this is another problem.

Hmm...
How can I reproduce it ?
It doesn't happen on my board.

I'm using
 linus/master + paul/sh-latest + sh73a0-irq-fixup-patch

# My kzm9g board is not mass-production board though


-------- log -------------------------------------------------
(snip)
rtc-rs5c372 0-0032: setting system clock to 2001-01-17 20:57:59 UTC (979765079) 
asoc-simple-card asoc-simple-card.0:  ak4642-hifi <-> fsia-dai mapping ok       
smsc911x smsc911x.0: eth0: SMSC911x/921x identified at 0xdf9e8000, IRQ: 419     
Sending DHCP requests .mmc0: SD Status: Invalid Allocation Unit size.           
mmc0: new SD card at address ee97                                               
mmcblk0: mmc0:ee97 S128B 122 MiB                                                
 mmcblk0: p1 p2                                                                 
mmc1: new high speed SDHC card at address b368                                  
mmcblk1: mmc1:b368 SD16G 14.4 GiB                                               
 mmcblk1: p1                                                                    
[sched_delayed] sched: RT throttling activated                                  
mmc2: new high speed MMC card at address 0001                                   
mmcblk2: mmc2:0001 M4G1EM 3.72 GiB                                              
 mmcblk2: unknown partition table                                               
., OK                                                                           
IP-Config: Got DHCP answer from 192.168.10.77, my address is 192.168.10.118     
IP-Config: Complete:                                                            
     device=eth0, addr\x192.168.10.118, mask%5.255.255.0, gw\x192.168.10.77     
     host\x192.168.10.118, domain=example.org, nis-domain=(none)                 


Best regards
---
Kuninori Morimoto

Re: kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

[Tetsuyuki Kobayashi]

Hi Moromoto-san

In my case this problem occurs once per 2 or 3 times, not every time.
I'm using v3.5rc2 + sh7a30-irq-fixup-patch.

I tried 2 kzm9g boards. One of them is almost same as yours.


(2012/08/21 11:31), Kuninori Morimoto wrote:
>
> Hi Kobayashi-san
>
>> After applying this patch on kzm9g board, I got this error regarding eMMC.
>> I think this is another problem.
>
> Hmm...
> How can I reproduce it ?
> It doesn't happen on my board.
>
> I'm using
>   linus/master + paul/sh-latest + sh73a0-irq-fixup-patch
>
> # My kzm9g board is not mass-production board though
>
>
> -------- log -------------------------------------------------
> (snip)
> rtc-rs5c372 0-0032: setting system clock to 2001-01-17 20:57:59 UTC (979765079)
> asoc-simple-card asoc-simple-card.0:  ak4642-hifi <-> fsia-dai mapping ok
> smsc911x smsc911x.0: eth0: SMSC911x/921x identified at 0xdf9e8000, IRQ: 419
> Sending DHCP requests .mmc0: SD Status: Invalid Allocation Unit size.
> mmc0: new SD card at address ee97
> mmcblk0: mmc0:ee97 S128B 122 MiB
>   mmcblk0: p1 p2
> mmc1: new high speed SDHC card at address b368
> mmcblk1: mmc1:b368 SD16G 14.4 GiB
>   mmcblk1: p1
> [sched_delayed] sched: RT throttling activated
> mmc2: new high speed MMC card at address 0001
> mmcblk2: mmc2:0001 M4G1EM 3.72 GiB
>   mmcblk2: unknown partition table
> ., OK
> IP-Config: Got DHCP answer from 192.168.10.77, my address is 192.168.10.118
> IP-Config: Complete:
>       device=eth0, addr\x192.168.10.118, mask%5.255.255.0, gw\x192.168.10.77
>       host\x192.168.10.118, domain=example.org, nis-domain=(none)
>
>
> Best regards
> ---
> Kuninori Morimoto
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: irqdomain breaks ap4 boot

[Tetsuyuki Kobayashi]

Simon-san,

This patch may be just a quick fix but could you apply this patch to 
kzm9g branch for convience ?


(2012/08/10 21:38), Paul Mundt wrote:

> I screwed up the multi-evt case, it should be trying to associate irq2,
> not irq. Try this:
>
> ---
>
> diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
> index 32c26d7..8f32a13 100644
> --- a/drivers/sh/intc/core.c
> +++ b/drivers/sh/intc/core.c
> @@ -355,7 +355,7 @@ int __init register_intc_controller(struct intc_desc *desc)
>   			if (unlikely(res)) {
>   				if (res = -EEXIST) {
>   					res = irq_domain_associate(d->domain,
> -								   irq, irq);
> +								   irq2, irq2);
>   					if (unlikely(res)) {
>   						pr_err("domain association "
>   						       "failure\n");
>

Re: irqdomain breaks ap4 boot

[Simon Horman]

Hi Kobayashi-san,

I'd rather only apply patches that are ready for upstream.
Is this patch suitable for merging upstream?

On Fri, Aug 31, 2012 at 03:55:09PM +0900, Tetsuyuki Kobayashi wrote:
> Simon-san,
> 
> This patch may be just a quick fix but could you apply this patch to
> kzm9g branch for convience ?
> 
> 
> (2012/08/10 21:38), Paul Mundt wrote:
> 
> >I screwed up the multi-evt case, it should be trying to associate irq2,
> >not irq. Try this:
> >
> >---
> >
> >diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
> >index 32c26d7..8f32a13 100644
> >--- a/drivers/sh/intc/core.c
> >+++ b/drivers/sh/intc/core.c
> >@@ -355,7 +355,7 @@ int __init register_intc_controller(struct intc_desc *desc)
> >  			if (unlikely(res)) {
> >  				if (res = -EEXIST) {
> >  					res = irq_domain_associate(d->domain,
> >-								   irq, irq);
> >+								   irq2, irq2);
> >  					if (unlikely(res)) {
> >  						pr_err("domain association "
> >  						       "failure\n");
> >
> 

Re: irqdomain breaks ap4 boot

[Paul Mundt]

On Fri, Aug 31, 2012 at 04:17:16PM +0900, Simon Horman wrote:
> Hi Kobayashi-san,
> 
> I'd rather only apply patches that are ready for upstream.
> Is this patch suitable for merging upstream?
> 
Yes, it's already in my tree and Linus-bound, I just haven't sent it yet
as I was waiting to see if anything else was broken first. The multi-evt
case is pretty uncommon, so there shouldn't be many platforms that even
care about this (I'd be surprised if anything on the ARM side does for
example).

Re: irqdomain breaks ap4 boot

[Tetsuyuki Kobayashi]

Hi Paul-san,

(2012/08/31 19:36), Paul Mundt wrote:
> On Fri, Aug 31, 2012 at 04:17:16PM +0900, Simon Horman wrote:
>> Hi Kobayashi-san,
>>
>> I'd rather only apply patches that are ready for upstream.
>> Is this patch suitable for merging upstream?
>>
> Yes, it's already in my tree and Linus-bound, I just haven't sent it yet
> as I was waiting to see if anything else was broken first. The multi-evt
> case is pretty uncommon, so there shouldn't be many platforms that even
> care about this (I'd be surprised if anything on the ARM side does for
> example).
>
Could you post this patch ?