From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751133AbdBTUyu (ORCPT ); Mon, 20 Feb 2017 15:54:50 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41487 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750830AbdBTUys (ORCPT ); Mon, 20 Feb 2017 15:54:48 -0500 Subject: Re: [next-20170217] WARN @/arch/powerpc/include/asm/xics.h:124 .icp_hv_eoi+0x40/0x140 From: Benjamin Herrenschmidt Reply-To: benh@au1.ibm.com To: Michael Ellerman , Sachin Sant , tglx@linutronix.de Cc: linuxppc-dev@ozlabs.org, linux-next@vger.kernel.org, LKML Date: Tue, 21 Feb 2017 07:53:44 +1100 In-Reply-To: <87mvdhgmhj.fsf@concordia.ellerman.id.au> References: <87zihhh9mp.fsf@concordia.ellerman.id.au> <15420F42-D2C6-4E29-8874-C47F4D61B098@linux.vnet.ibm.com> <87mvdhgmhj.fsf@concordia.ellerman.id.au> Organization: IBM Australia Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.4 (3.22.4-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17022020-0048-0000-0000-00000207BFA5 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17022020-0049-0000-0000-000047915BFB Message-Id: <1487624024.23576.181.camel@au1.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-20_17:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702200194 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.