help with unhandled IRQ error with mpt2sas driver and powerpc 460EX

help with unhandled IRQ error with mpt2sas driver and powerpc 460EX

[Ayman El-Khashab]

Hello, I am using the mpt2sas driver on the canyonlands / 460EX board.  
I've already found and fixed one problem, but can't get past the 
unhandled IRQ.

The first problem I noticed is that the physical address is read into a 
32 bit variable, but the 460ex has a 36 bit bus so the ioremap would 
always fail.  I've change the defn of chip_phys in mpt2sas_base.h to u64 
and that cleared up that issue.   As soon as the unmask_interrupts 
method is called (or not long after), I get an interrupt -- presumably 
from the sas controller.  If I comment out the unmask, the interrupt 
never occurs.  If I unmask them, I get the interrupt.  I've traced the 
code through the interrupt handler all the way to ~ line 757.

 rpf = &ioc->reply_post_free[ioc->reply_post_host_index];

I've verified that at the end of this, IRQ_NONE is returned.  At this 
point the kernel prints the following -- the last statements lead me to 
think that the sas controller expected something but never got it.  I am 
unsure how to proceed at this point.  I am using a denx kernel head 
pulled from git today since there were some changes to thsi driver for 
endian issues.

irq 18: nobody cared (try booting with the "irqpoll" option)
Call Trace:
[c0367df0] [c0005eac] show_stack+0x44/0x16c (unreliable)
[c0367e30] [c004eedc] __report_bad_irq+0x34/0xb8
[c0367e50] [c004f118] note_interrupt+0x1b8/0x224
[c0367e80] [c004ff50] handle_level_irq+0xa0/0x11c
[c0367e90] [c0018ba4] uic_irq_cascade+0xf8/0x12c
[c0367eb0] [c00041d0] do_IRQ+0x98/0xb4
[c0367ed0] [c000df40] ret_from_except+0x0/0x18
[c0367f90] [c0006ed8] cpu_idle+0x50/0xd8
[c0367fb0] [c000197c] rest_init+0x5c/0x70
[c0367fc0] [c0320848] start_kernel+0x224/0x2a0
[c0367ff0] [c0000200] skpinv+0x190/0x1cc
handlers:
[<c01aba98>] (_base_interrupt+0x0/0x8f8)
Disabling IRQ #18
mpt2sas0: _base_event_notification: timeout
mf:
        07000000 00000000 00000000 00000000 00000000 0f2f3fff fffffffc 
ffffffff
        ffffffff 00000000 00000000
mpt2sas0: sending diag reset !!
mpt2sas0: diag reset: SUCCESS
mpt2sas0: failure at 
drivers/scsi/mpt2sas/mpt2sas_scsih.c:5989/_scsih_probe()!

Thanks
Ayman

Re: help with unhandled IRQ error with mpt2sas driver and powerpc 460EX

[Benjamin Herrenschmidt]

On Tue, 2009-10-27 at 12:27 -0500, Ayman El-Khashab wrote:
> 
> The first problem I noticed is that the physical address is read into a 
> 32 bit variable, but the 460ex has a 36 bit bus so the ioremap would 
> always fail.  I've change the defn of chip_phys in mpt2sas_base.h to u64 
> and that cleared up that issue.

That looks indeed like a common driver bug. Please make sure you submit
the fix upstream. The "right" type to use is resource_size_t in fact.

>    As soon as the unmask_interrupts 
> method is called (or not long after), 

What exactly is that "method" ? IE. A driver function that enables
emission of interrupts on the device ?

> I get an interrupt -- presumably 
> from the sas controller.  If I comment out the unmask, the interrupt 
> never occurs.  If I unmask them, I get the interrupt.  I've traced the 
> code through the interrupt handler all the way to ~ line 757.

Unmask at what level ? The linux level (enable_irq() -> UIC unmask) or
the card level ?

>  rpf = &ioc->reply_post_free[ioc->reply_post_host_index];
> 
> I've verified that at the end of this, IRQ_NONE is returned.  At this 
> point the kernel prints the following -- the last statements lead me to 
> think that the sas controller expected something but never got it.  I am 
> unsure how to proceed at this point.  I am using a denx kernel head 
> pulled from git today since there were some changes to thsi driver for 
> endian issues.

Well, if the interrupt is indeed coming from the card and the driver's
interrupt handler can't figure it out, then you are facing a bug in the
driver. I would recommend you work with whoever is maintaining that
driver to help sort it out.

Cheers,
Ben.

> irq 18: nobody cared (try booting with the "irqpoll" option)
> Call Trace:
> [c0367df0] [c0005eac] show_stack+0x44/0x16c (unreliable)
> [c0367e30] [c004eedc] __report_bad_irq+0x34/0xb8
> [c0367e50] [c004f118] note_interrupt+0x1b8/0x224
> [c0367e80] [c004ff50] handle_level_irq+0xa0/0x11c
> [c0367e90] [c0018ba4] uic_irq_cascade+0xf8/0x12c
> [c0367eb0] [c00041d0] do_IRQ+0x98/0xb4
> [c0367ed0] [c000df40] ret_from_except+0x0/0x18
> [c0367f90] [c0006ed8] cpu_idle+0x50/0xd8
> [c0367fb0] [c000197c] rest_init+0x5c/0x70
> [c0367fc0] [c0320848] start_kernel+0x224/0x2a0
> [c0367ff0] [c0000200] skpinv+0x190/0x1cc
> handlers:
> [<c01aba98>] (_base_interrupt+0x0/0x8f8)
> Disabling IRQ #18
> mpt2sas0: _base_event_notification: timeout
> mf:
>         07000000 00000000 00000000 00000000 00000000 0f2f3fff fffffffc 
> ffffffff
>         ffffffff 00000000 00000000
> mpt2sas0: sending diag reset !!
> mpt2sas0: diag reset: SUCCESS
> mpt2sas0: failure at 
> drivers/scsi/mpt2sas/mpt2sas_scsih.c:5989/_scsih_probe()!
> 
> Thanks
> Ayman
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 
> 

Re: help with unhandled IRQ error with mpt2sas driver and powerpc 460EX

[Ayman El-Khashab]

On 10/27/2009 7:22 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2009-10-27 at 12:27 -0500, Ayman El-Khashab wrote:
>   
>> The first problem I noticed is that the physical address is read into a 
>> 32 bit variable, but the 460ex has a 36 bit bus so the ioremap would 
>> always fail.  I've change the defn of chip_phys in mpt2sas_base.h to u64 
>> and that cleared up that issue.
>>     
>
> That looks indeed like a common driver bug. Please make sure you submit
> the fix upstream. The "right" type to use is resource_size_t in fact.
>
>   
Thank you Benjamin for your help.  The info was passed onto the 
maintainer and they were able to use it
to improve their driver.  In the background, the mpt2sas was brought up 
on the canyonlands/460ex.  The
biggest thing turned out to be an #ifdef in the code that referred to 
BITS_32 to determine whether to prog
the high and low of the DMA addresses.  Once that was adjusted, it did 
function and detect the sas drive.