From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-02-20 02:35:45
Sachin Sant [off-list ref] writes:
While booting next-20170217 on a POWER6 box, I ran into following
warning. This is a full system lpar. Previous next tree was good.
I will try a bisect tomorrow.
On Sun, 2017-02-19 at 20:39 +0530, Sachin Sant wrote:
While booting next-20170217 on a POWER6 box, I ran into following
warning. This is a full system lpar. Previous next tree was good.
I will try a bisect tomorrow.
ipr: IBM Power RAID SCSI Device Driver version: 2.6.3 (October 17, 2015)
ipr 0200:00:01.0: Found IOA with IRQ: 305
------------[ cut here ]------------
WARNING: CPU: 12 PID: 1 at ./arch/powerpc/include/asm/xics.h:124 .icp_hv_eoi+0x40/0x140
This indicates that the CPPR stack underflow'd (we don't know the CPPR value
at the time of the interrupt that we are going to do an EOI for). The problem
could have occured elsewhere, but shows up at the first interrupt after
the real cause. Could you past the full dmesg and config and follow Michael's
suggestion for debugging SHIRQ's
Balbir
From: Sachin Sant <hidden> Date: 2017-02-20 05:07:27
quoted
While booting next-20170217 on a POWER6 box, I ran into following
warning. This is a full system lpar. Previous next tree was good.
I will try a bisect tomorrow.
=20
Do you have CONFIG_DEBUG_SHIRQ=3Dy ?
=20
Yes. CONFIG_DEBUG_SHIRQ is enabled.
As suggested by you reverting following commit allows a clean boot.
f91f694540f3 ("genirq: Reenable shared irq debugging in =
request_*_irq()=E2=80=9D)
quoted
ipr: IBM Power RAID SCSI Device Driver version: 2.6.3 (October 17, =
2015)
quoted
ipr 0200:00:01.0: Found IOA with IRQ: 305
------------[ cut here ]------------
WARNING: CPU: 12 PID: 1 at ./arch/powerpc/include/asm/xics.h:124 =
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-02-20 10:56:41
Sachin Sant [off-list ref] writes:
quoted
quoted
While booting next-20170217 on a POWER6 box, I ran into following
warning. This is a full system lpar. Previous next tree was good.
I will try a bisect tomorrow.
=20
Do you have CONFIG_DEBUG_SHIRQ=3Dy ?
=20
Yes. CONFIG_DEBUG_SHIRQ is enabled.
As suggested by you reverting following commit allows a clean boot.
f91f694540f3 ("genirq: Reenable shared irq debugging in request_*_irq()=
=E2=80=9D)
OK. Or disabling CONFIG_DEBUG_SHIRQ :)
The problem is that the xics code saves the CPPR value in get_irq(),
called from __do_irq(), and then restores it in irq_eoi().
But when we're called for CONFIG_DEBUG_SHIRQ get_irq() is not called,
precisely because we're faking an interrupt.
I'm not sure if there's a good way to fix it :/
cheers
quoted
quoted
ipr: IBM Power RAID SCSI Device Driver version: 2.6.3 (October 17, 2015)
ipr 0200:00:01.0: Found IOA with IRQ: 305
------------[ cut here ]------------
WARNING: CPU: 12 PID: 1 at ./arch/powerpc/include/asm/xics.h:124 .icp_h=
From: Benjamin Herrenschmidt <hidden> Date: 2017-02-20 20:54:50
On Mon, 2017-02-20 at 21:55 +1100, Michael Ellerman wrote:
But when we're called for CONFIG_DEBUG_SHIRQ get_irq() is not called,
precisely because we're faking an interrupt.
I'm not sure if there's a good way to fix it :/
In the irq_replay path we have code to adjust the CPPR stack. We could
do something similar.
HOWEVER. Looking at current upstream code I don't understand the error,
the DEBUG_SHIRQ code is calling the driver's handler not the flow
handler so it shouldn't be called handle_fasteoi_irq or am I missing
something ?
Cheers,
Ben.
From: Thomas Gleixner <hidden> Date: 2017-02-20 22:04:23
On Tue, 21 Feb 2017, Benjamin Herrenschmidt wrote:
On Mon, 2017-02-20 at 21:55 +1100, Michael Ellerman wrote:
quoted
But when we're called for CONFIG_DEBUG_SHIRQ get_irq() is not called,
precisely because we're faking an interrupt.
I'm not sure if there's a good way to fix it :/
In the irq_replay path we have code to adjust the CPPR stack. We could
do something similar.
HOWEVER. Looking at current upstream code I don't understand the error,
the DEBUG_SHIRQ code is calling the driver's handler not the flow
handler so it shouldn't be called handle_fasteoi_irq or am I missing
something ?
I tried to invoke the normal handler path which also invokes the flow
handler, but that breaks on x86 as well for different reasons. I zapped
that commit and still need to find a way to do that debug thing proper. So
it's appearence in -next was only temporary.
Thanks,
tglx
From: Benjamin Herrenschmidt <hidden> Date: 2017-02-20 22:19:23
On Mon, 2017-02-20 at 14:04 -0800, Thomas Gleixner wrote:
quoted
HOWEVER. Looking at current upstream code I don't understand the error,
the DEBUG_SHIRQ code is calling the driver's handler not the flow
handler so it shouldn't be called handle_fasteoi_irq or am I missing
something ?
I tried to invoke the normal handler path which also invokes the flow
handler, but that breaks on x86 as well for different reasons. I zapped
that commit and still need to find a way to do that debug thing proper. So
it's appearence in -next was only temporary.
Ok I see. Yes I wouldn't be surprised if we aren't the only ones to
expect that one get_irq() matches *one* invocation of the flow handler.
We had to hack around this for irq_replay already but at least we have
a hook to do that.
You could possibly use replay, but what's wrong with what the code
currently does which is to just call the driver handler directly ?
Cheers,
Ben.