From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1945919AbcA1Q26 (ORCPT ); Thu, 28 Jan 2016 11:28:58 -0500 Received: from www.linutronix.de ([62.245.132.108]:33590 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161294AbcA1Q2w (ORCPT ); Thu, 28 Jan 2016 11:28:52 -0500 Date: Thu, 28 Jan 2016 17:27:46 +0100 (CET) From: Thomas Gleixner To: Ulf Hansson cc: Russell King - ARM Linux , Haibo Chen , linux-mmc , "linux-kernel@vger.kernel.org" , Jon Hunter Subject: Re: [PATCH] mmc: sdhci: disable irq in sdhci host suspend ranther than free this irq In-Reply-To: Message-ID: References: <1453974146-20951-1-git-send-email-haibo.chen@nxp.com> <20160128102057.GJ10826@n2100.arm.linux.org.uk> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 28 Jan 2016, Thomas Gleixner wrote: > On Thu, 28 Jan 2016, Ulf Hansson wrote: > > Therefore, the only way we currently can make sure to don't get the > > IRQ is to free and later re-request it. Now, apparently that has > > issues when using threaded IRQ handlers. > > What's the issue? Ah, you mean that one: > Currently sdhci driver free irq in host suspend, and call > request_threaded_irq() in host resume. But during host resume, > Ctrl+C can impact sdhci host resume, see the error log: > CPU1 is up > PM: noirq resume of devices complete after 0.637 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.1 > PM: early resume of devices complete after 0.774 msecs > dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4 > PM: Device 30b40000.usdhc failed to resume: error -4 > dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4 > PM: Device 30b50000.usdhc failed to resume: error -4 > dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4 > PM: Device 30b60000.usdhc failed to resume: error -4 fec 30be0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx > mmc0: Timeout waiting for hardware interrupt. > mmc0: Timeout waiting for hardware interrupt. > mmc0: Timeout waiting for hardware interrupt. > mmc0: Timeout waiting for hardware interrupt. > mmc0: Timeout waiting for hardware interrupt. > mmc0: Timeout waiting for hardware interrupt. > mmc0: error -110 during resume (card was removed?) > mmc2: Timeout waiting for hardware interrupt. > mmc2: Timeout waiting for hardware interrupt. > mmc2: error -110 during resume (card was removed?) In request_threaded_irq-> __setup_irq-> kthread_create ->kthread_create_on_node, the comment shows that SIGKILLed will impact the kthread create, and return -EINTR. And how should that thread be SIGKILLed? Hitting Ctrl+C on the console does not affect any kernel internal thread. Hitting Ctrl+C affects solely the process which is running on that console. And if it would, then that would be a completely different, serious bug which needs to be fixed. How was verified, that the thread was not created and that the creation failed due to a SIGKILL? Thanks, tglx