From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752746AbcD0IxK (ORCPT ); Wed, 27 Apr 2016 04:53:10 -0400 Received: from mail-qg0-f67.google.com ([209.85.192.67]:35058 "EHLO mail-qg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751411AbcD0IxH (ORCPT ); Wed, 27 Apr 2016 04:53:07 -0400 MIME-Version: 1.0 In-Reply-To: <1f10ab4830032858bc4d6174528f18e8@agner.ch> References: <1454107764-19876-1-git-send-email-stefan@agner.ch> <20160421034520.GA19965@shlinux2.ap.freescale.net> <20160426012341.GB8870@tiger> <1461663072.7839.17.camel@pengutronix.de> <20160427015835.GE30692@tiger> <1f10ab4830032858bc4d6174528f18e8@agner.ch> Date: Wed, 27 Apr 2016 16:53:06 +0800 Message-ID: Subject: Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled From: Dong Aisheng To: Stefan Agner Cc: Fabio Estevam , Shawn Guo , Lucas Stach , Michael Turquette , Stephen Boyd , "linux-kernel@vger.kernel.org" , mingo@redhat.com, "kernel@pengutronix.de" , Thomas Gleixner , linux-clk@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 27, 2016 at 3:28 PM, Stefan Agner wrote: > On 2016-04-26 19:56, Fabio Estevam wrote: >> On Tue, Apr 26, 2016 at 11:45 PM, Dong Aisheng wrote: >> >>>> We need to firstly understand why this is happening. The .prepare hook >>>> is defined to be non-atomic context, and so that we call sleep function >>>> in there. We did everything right. Why are we getting the warning? If >>>> I'm correct, this warning only happens on i.MX7D. Why is that? >>>> >>> >>> This is mainly caused by during kernel early booting, there's only one init idle >>> task running. >>> See: >>> void __init sched_init(void) >>> { >>> ..... >>> /* >>> * Make us the idle thread. Technically, schedule() should not be >>> * called from this thread, however somewhere below it might be, >>> * but because we are the idle thread, we just pick up running again >>> * when this runqueue becomes "idle". >>> */ >>> init_idle(current, smp_processor_id()); >>> ... >>> } >>> >>> And the idle sched class indicates it's not valid to schedule for idle task. >>> const struct sched_class idle_sched_class = { >>> /* .next is NULL */ >>> /* no enqueue/yield_task for idle tasks */ >>> >>> /* dequeue is not valid, we print a debug message there: */ >>> .dequeue_task = dequeue_task_idle, >>> ........... >>> >>> } >>> >>> /* >>> * It is not legal to sleep in the idle task - print a warning >>> * message if some code attempts to do it: >>> */ >>> static void >>> dequeue_task_idle(struct rq *rq, struct task_struct *p, int flags) >>> { >>> raw_spin_unlock_irq(&rq->lock); >>> printk(KERN_ERR "bad: scheduling from the idle thread!\n"); >>> dump_stack(); >>> raw_spin_lock_irq(&rq->lock); >>> } >>> >>> >>> Below is the full log of imx7d booting FYI. >> >> This does not answer Shawn's question: why do we see this only on mx7d? > > I was wondering that too.... My theory is that either on i.MX 6 the > clocks enable almost instantly leading to no sleep, or they are just > bootloader/firmware on...? > Yes, for core plls, they're already enabled in bootloader. We observed this issue on MX7D is because we rudely enable all clocks for it and MX7D AV PLLs which will lead to sleep reveals this issue. Regards Dong Aisheng > -- > Stefan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <1f10ab4830032858bc4d6174528f18e8@agner.ch> References: <1454107764-19876-1-git-send-email-stefan@agner.ch> <20160421034520.GA19965@shlinux2.ap.freescale.net> <20160426012341.GB8870@tiger> <1461663072.7839.17.camel@pengutronix.de> <20160427015835.GE30692@tiger> <1f10ab4830032858bc4d6174528f18e8@agner.ch> Date: Wed, 27 Apr 2016 16:53:06 +0800 Message-ID: Subject: Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled From: Dong Aisheng To: Stefan Agner Cc: Fabio Estevam , Shawn Guo , Lucas Stach , Michael Turquette , Stephen Boyd , "linux-kernel@vger.kernel.org" , mingo@redhat.com, "kernel@pengutronix.de" , Thomas Gleixner , linux-clk@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 List-ID: On Wed, Apr 27, 2016 at 3:28 PM, Stefan Agner wrote: > On 2016-04-26 19:56, Fabio Estevam wrote: >> On Tue, Apr 26, 2016 at 11:45 PM, Dong Aisheng wrote: >> >>>> We need to firstly understand why this is happening. The .prepare hook >>>> is defined to be non-atomic context, and so that we call sleep function >>>> in there. We did everything right. Why are we getting the warning? If >>>> I'm correct, this warning only happens on i.MX7D. Why is that? >>>> >>> >>> This is mainly caused by during kernel early booting, there's only one init idle >>> task running. >>> See: >>> void __init sched_init(void) >>> { >>> ..... >>> /* >>> * Make us the idle thread. Technically, schedule() should not be >>> * called from this thread, however somewhere below it might be, >>> * but because we are the idle thread, we just pick up running again >>> * when this runqueue becomes "idle". >>> */ >>> init_idle(current, smp_processor_id()); >>> ... >>> } >>> >>> And the idle sched class indicates it's not valid to schedule for idle task. >>> const struct sched_class idle_sched_class = { >>> /* .next is NULL */ >>> /* no enqueue/yield_task for idle tasks */ >>> >>> /* dequeue is not valid, we print a debug message there: */ >>> .dequeue_task = dequeue_task_idle, >>> ........... >>> >>> } >>> >>> /* >>> * It is not legal to sleep in the idle task - print a warning >>> * message if some code attempts to do it: >>> */ >>> static void >>> dequeue_task_idle(struct rq *rq, struct task_struct *p, int flags) >>> { >>> raw_spin_unlock_irq(&rq->lock); >>> printk(KERN_ERR "bad: scheduling from the idle thread!\n"); >>> dump_stack(); >>> raw_spin_lock_irq(&rq->lock); >>> } >>> >>> >>> Below is the full log of imx7d booting FYI. >> >> This does not answer Shawn's question: why do we see this only on mx7d? > > I was wondering that too.... My theory is that either on i.MX 6 the > clocks enable almost instantly leading to no sleep, or they are just > bootloader/firmware on...? > Yes, for core plls, they're already enabled in bootloader. We observed this issue on MX7D is because we rudely enable all clocks for it and MX7D AV PLLs which will lead to sleep reveals this issue. Regards Dong Aisheng > -- > Stefan From mboxrd@z Thu Jan 1 00:00:00 1970 From: dongas86@gmail.com (Dong Aisheng) Date: Wed, 27 Apr 2016 16:53:06 +0800 Subject: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled In-Reply-To: <1f10ab4830032858bc4d6174528f18e8@agner.ch> References: <1454107764-19876-1-git-send-email-stefan@agner.ch> <20160421034520.GA19965@shlinux2.ap.freescale.net> <20160426012341.GB8870@tiger> <1461663072.7839.17.camel@pengutronix.de> <20160427015835.GE30692@tiger> <1f10ab4830032858bc4d6174528f18e8@agner.ch> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Apr 27, 2016 at 3:28 PM, Stefan Agner wrote: > On 2016-04-26 19:56, Fabio Estevam wrote: >> On Tue, Apr 26, 2016 at 11:45 PM, Dong Aisheng wrote: >> >>>> We need to firstly understand why this is happening. The .prepare hook >>>> is defined to be non-atomic context, and so that we call sleep function >>>> in there. We did everything right. Why are we getting the warning? If >>>> I'm correct, this warning only happens on i.MX7D. Why is that? >>>> >>> >>> This is mainly caused by during kernel early booting, there's only one init idle >>> task running. >>> See: >>> void __init sched_init(void) >>> { >>> ..... >>> /* >>> * Make us the idle thread. Technically, schedule() should not be >>> * called from this thread, however somewhere below it might be, >>> * but because we are the idle thread, we just pick up running again >>> * when this runqueue becomes "idle". >>> */ >>> init_idle(current, smp_processor_id()); >>> ... >>> } >>> >>> And the idle sched class indicates it's not valid to schedule for idle task. >>> const struct sched_class idle_sched_class = { >>> /* .next is NULL */ >>> /* no enqueue/yield_task for idle tasks */ >>> >>> /* dequeue is not valid, we print a debug message there: */ >>> .dequeue_task = dequeue_task_idle, >>> ........... >>> >>> } >>> >>> /* >>> * It is not legal to sleep in the idle task - print a warning >>> * message if some code attempts to do it: >>> */ >>> static void >>> dequeue_task_idle(struct rq *rq, struct task_struct *p, int flags) >>> { >>> raw_spin_unlock_irq(&rq->lock); >>> printk(KERN_ERR "bad: scheduling from the idle thread!\n"); >>> dump_stack(); >>> raw_spin_lock_irq(&rq->lock); >>> } >>> >>> >>> Below is the full log of imx7d booting FYI. >> >> This does not answer Shawn's question: why do we see this only on mx7d? > > I was wondering that too.... My theory is that either on i.MX 6 the > clocks enable almost instantly leading to no sleep, or they are just > bootloader/firmware on...? > Yes, for core plls, they're already enabled in bootloader. We observed this issue on MX7D is because we rudely enable all clocks for it and MX7D AV PLLs which will lead to sleep reveals this issue. Regards Dong Aisheng > -- > Stefan