[ofa-general] ipath irq bug

[Robert Walsh]

Roland Dreier wrote:
>  > [ 2651.241648]  [<ffffffff80478444>] _spin_unlock_irq+0x28/0x2d
>  > [ 2651.247482]  [<ffffffff880a0769>] :ib_ipath:ipath_rc_rcv+0xf5b/0xf8e
>  > [ 2651.254058]  [<ffffffff8809d1ff>] :ib_ipath:ipath_lookup_qpn+0x4f/0x5a
>  > [ 2651.260791]  [<ffffffff880a5f40>] :ib_ipath:ipath_qp_rcv+0x45/0x4e
>  > [ 2651.267203]  [<ffffffff880a60b3>] :ib_ipath:ipath_ib_rcv+0x16a/0x1a8
>  > [ 2651.273784]  [<ffffffff88090a3e>] :ib_ipath:ipath_kreceive+0x42f/0x6b9
>  > [ 2651.286397]  [<ffffffff880a6b02>] :ib_ipath:ipath_ib_piobufavail+0x72/0x79
>  > [ 2651.321572]  [<ffffffff8809932c>] :ib_ipath:ipath_intr+0x26a/0x17b6
> 
> [edited slightly]
> 
> It looks like ipath_intr() (presumably the interrupt handler) ends up
> in ipath_rc_rcv() and in particular in ipath_rc_rcv_error() (which is
> inlined), which calls spin_unlock_irq() from interrupt context, which
> is the problem.
> 
> Someone who knows the driver better than I would have to confirm this
> analysis, and decide whether the fix is just to switch to
> spin_lock_irqsave() in ipath_rc_rcv_error(), or if it needs to be more
> elaborate.

Yeah - that's it.  We've just fixed it internally and will be sending a 
patch out shortly.

Regards,
  Robert.